onreset and Mozilla

P

Peter Adolphs

Hi newsgroup!

The W3C HTML 4.01 recommendation states that "The onreset event occurs
when a form is reset." Using Mozilla 1.4.1, how come that if I set
onreset="return false;", the form is not reset at all? Is this a bug?
I've attached an HTML page to reproduce the behaviour.

Bye,
Peter.
 
P

Peter Adolphs

Peter said:
The W3C HTML 4.01 recommendation states that "The onreset event occurs
when a form is reset." Using Mozilla 1.4.1, how come that if I set
onreset="return false;", the form is not reset at all? Is this a bug?
I've attached an HTML page to reproduce the behaviour.

Hmmm, if I test the attachment directly in Mozilla Mail, it's behaving
correctly. The described behaviour only shows up if the page is viewed
in Mozilla Navigator... Well, now it really looks like a bug to me.

Peter.
 
K

kaeli

Hi newsgroup!

The W3C HTML 4.01 recommendation states that "The onreset event occurs
when a form is reset." Using Mozilla 1.4.1, how come that if I set
onreset="return false;", the form is not reset at all?

Because you cancelled the reset by returning false.
Try onreset="alert('hi!')" and watch if it goes.
Is this a bug?

I doubt it.


--
 
P

Peter Adolphs

kaeli said:
Because you cancelled the reset by returning false.
Try onreset="alert('hi!')" and watch if it goes.

Well, but this is compliant to the spec. The alert window is shown when
the form is reset. In my case, it is not reset since I return false. But
why? Where does it say that returning false cancels the action of an
event handler? That would mean that an event handler can undo an event
which it is supposed to react to. ???

Peter.
 
P

Peter Adolphs

Peter said:
Hmmm, if I test the attachment directly in Mozilla Mail, it's behaving
correctly.

.... of course only when JavaScript is not activated in Mozilla Mail. :)

Peter.
 
K

kaeli

Well, but this is compliant to the spec. The alert window is shown when
the form is reset. In my case, it is not reset since I return false. But
why? Where does it say that returning false cancels the action of an
event handler?

Um, standards? I don't know.

It's always done that, AFAIK.
Like when you submit a form and have a handler, like
<form onSubmit="return validate(this)">
and the validate returns false, the form doesn't submit.

Others on this group could answer this way better than I.
I just code. Others know the standards way more than I do.

--
--
~kaeli~
Kill one man and you are a murderer. Kill millions and you
are a conqueror. Kill everyone and you are God.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace
 
G

Grant Wagner

Peter said:
Well, but this is compliant to the spec. The alert window is shown when
the form is reset. In my case, it is not reset since I return false. But
why? Where does it say that returning false cancels the action of an
event handler? That would mean that an event handler can undo an event
which it is supposed to react to. ???

Peter.

Event handlers can't "undo" anything, but they can prevent the action that
triggered the event from "bubbling up" and being handled by some other aspect
of the Web browser or operating system. Examples of this are:

<input type="text" onkeypress="return false;">
<a href="http://www.yahoo.com" onclick="return false;">
<form onsubmit="return false;">

Obviously you wouldn't just "return false;" from these events, so something
more useful is:

<script type="text/javascript">
function positiveIntInputOnly(e) {
var k;
if (e && e.which) { // NS
k = e.which;
} else if (window.event && window.event.keyCode) { // IE
k = window.event.keyCode;
}
return (!k || ((k > 47 && k < 58) || k == 8));
}
</script>
<input type="text" onkeypress="return positiveIntInputOnly(event);">

<a href="http://www.yahoo.com" onclick="window.open(this.href);return
false;"> <!-- note this is really a bad idea, but I couldn't think of a
better example, well I can, but it involves changing <tbody> display style
attributes vs. reloading the page to display the rows inside the <tbody> for
fall-back to browsers that can't dynamically change the display style
attribute -->

<script type="text/javascript">
function validate(f) {
if (f.someInput && f.someInput == 'some value') {
return true;
} else {
return false;
}
}
</script>
<form onsubmit="return validate(this);">


--
| Grant Wagner <[email protected]>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-developer/upgrade_2.html
 
M

Michael Winter

On Thu, 29 Apr 2004 20:52:04 GMT, Grant Wagner

[snip]
Event handlers can't "undo" anything, but they can prevent the action
that triggered the event from "bubbling up" and being handled by some
other aspect of the Web browser or operating system.

Bubbling and cancelling are two completely different things, and you
appear to have confused them.

Assuming event propagation isn't interrupted, a dispatched event will flow
from the document root in a pre-determined route towards the target
element, firing any capturing listeners as it goes[1]. Once it reaches the
target, it fires all of the listeners there (except capturing listeners),
and then bubbles back up the document tree the way it came. Once the event
reaches the document root again and has finished firing all listeners, the
browser then, and only then, performs the default action for that event
type (if one exists).

If, at any point, a listener returns false (in the old model), calls
preventDefault() (in the DOM model) or sets returnValue to false (in the
IE model), the event continues as I previously described except that the
default action is not executed. No change to the event flow occurs.

Under the IE and DOM event models, you can stop propagation during any of
the three phases: capture, at target, or bubbling. You do this in IE by
setting the cancelBubble property of the event to true, or by calling
stopPropagation() method of the event. All listeners on the current
element fire, but the event will not proceed to the next element. If the
event hasn't been cancelled, the default action will then occur.

[snip]
function validate(f) {
if (f.someInput && f.someInput == 'some value') {
return true;
} else {
return false;
}
}

Wouldn't it be better to write...

return( f.someInput && ( f.someInput == 'some value' ));

....?

[snip]

Mike

[1] It should be noted that IE doesn't support event capture, so this
phase is skipped.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,431
Messages
2,571,678
Members
48,796
Latest member
Greg L.

Latest Threads

Top