Blog

Interesting JavaScript quirk w/ stopPropagation()

I'm developing my app, using Firefox, and in one of the files, I have the following javascript:

el = document.getElementById( "frmProcess" ); addEvent( el, "submit", validate );

Simple enough, right? I have a form called "frmProcess", and when that form's "submit" event fires off, I want the function validate() to fire off as well.

That part works fine, and as you may have guessed, validate(), well, validates some data in the given form. If the validation fails, it calls this line of code:

evt.stopPropagation();

...which doesn't work. The "submit" event doesn't stop running. The form happily submits itself as if nothing went wrong. After somedebugging I found 2 things:

1. Changing the offending line of code from "evt.stopPropagation();" to "evt.preventDefault();" fixes the issue.

2. evt.stopPropagation() worked just fine on other events (blur, click, etc). But if I attach the "submit" event, it bombs.

Now the million dollar question is: WHY!?!?!

Firefox didn't report an error, and nothing else seemed to be causing an issue. So WHY in the name of all that's good does a "submit" event have to be handled differently than other events? Is this a bug in Firefox? Some valid DOM thing that I just can't find documentation for?

--n

TweetBacks
Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
Default event and event propagation are slightly different things, which is why one worked and the other did not. Stopping event propagation has to do with even collecting and event bubbling. So, for example, if someone CLICKED the Submit button, normally the click Event would be captured by the button, then by the Form element, then by the Body (assuming no other "parent" elements exist). When stop event propagation on the Click, it prevents the event object from bubbling up into its parents.

Preventing a default action is related to event-triggers, but not quite to the event object. For example, when you click on a HREF link the "default behavior" of the browser is to change the URL. If you click, the browser BOTH propagates the click event AND preforms the default action (changing the URL). So, to stop the URL change (or the form submission) you have to kill the default behavior (this however, may still mean the event propagation / bubbling is still taking place).

I am new to event handling, but this is based on what I just learned.
# Posted By Ben Nadel | 11/5/07 1:15 PM
Ben is absolutely right on this. In your case of form validation, to prevent the form from forwarding to the action page you would return false to your submit, which would then stop the default action of the submit. The same would hold true for the click event of an anchor tag. The default action is to load the href in the browser (or the target you defined), but you could easily capture the click event to load the href into another div on the page (via an Ajax call) if you return false to the click event itself.
# Posted By Cutter | 11/5/07 11:01 PM
I am doing a 10-page report on Javascript, so I better be able to answer this by the time my paper is due in a coupleof weeks. I do not know the answer at this time. I'm inexperienced with event-based programming; I would probably have made a form WITHOUT A SUBMIT BUTTON and then make a blank button that calls 'validateAndSubmit()' when clicked, but that might be sloppy programming.

In my paper research I dug up some interesting lectures (I think they are from Yahoo engineers?) They attack the language from a pure, programming language standpoint rather then teaching it to you as a tool to manipulate the DOM. Also I think the advanced section talks about efficiency.


(shamelessly recycled from http://www.catonmat.net/blog/learning-javascript-p... since I'm not gonna depend on a 2-link deep reference so I will copy it here)

I'm 1/2 through part 3 of this 4-part intro lecture series:

(EVERYTHING below is copied from the URL refenced above)

<a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... Video Lecture Part I</a>
<a href="http://video.yahoo.com/video/play?vid=111594"... Video Lecture Part II</a>
<a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... Video Lecture Part III</a>
<a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... Video Lecture Part IV</a>

<p>Sometimes Yahoo! Video gives this error: <strong>Sorry! This video is no longer available on Yahoo! Video.</strong> In this case refresh your browser a couple of times!</p>
<p>The next three lectures are on Advanced JavaScript:</p>

<a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... JS Part I</a>
<a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... JS Part II</a>
<a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... JS Part III</a>


<p>Then there are 6 more lectures on JavaScript which should probably be viewed only after you have viewed the ones just mentioned.</p>

Advancing JavaScript with Libraries - <a href="http://video.yahoo.com/video/play?vid=410472"... I</a> and <a href="http://video.yahoo.com/video/play?vid=412541"... II</a></li>
<a href="http://video.yahoo.com/video/play?vid=568351"... JavaScript</a></li>
An Inconvenient API: The Theory of the DOM - <a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... I</a>, <a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... II</a> and <a href="http://video.yahoo.com/video/play?vid=cccd4aa02a39... III</a></li>


<p>Viewing the <a href="http://developer.yahoo.com/yui/theater/">Y... Theater</a> I just found another JavaScript lecture which was published just recently:</p>

<a href="http://video.yahoo.com/video/play?vid=630959"... - The Good Stuff</a>
# Posted By Eden | 11/6/07 10:38 PM
Pay special attention to the intro lecture 3. You might be able to do something crazy with the lambda functions, like have your function grab the current 'frmProcess' and replace it with a copy of validate IN FRONT OF the frmProcess (throwing an exception or halting execution in some other way. Or maybe I'm just an idealistic computer science student right now, learning about lisp and stuff, I dunno....
# Posted By Eden | 11/6/07 10:41 PM
Thanks for the feedback everyone.

In the end, I ended up re-writing a big chunk of this library so it no longer passes around events. Instead, I build up an array of anonymous functions, executing them in succession until I get one that returns "false". This seems to be working much better than my initial idea (and should be more cross-browser friendly when I have to start supporting IE).

thanks again.
n
# Posted By Nolan | 11/7/07 6:18 PM

Recent Comments

CF Objective Recap and Highlights
Jason Dean said: Thanks, Nolan! [More]

CF Objective Notes - What's a Pull Request? (Contributing to Open Source)
Brad Wood said: Thanks for posting your notes! Here the full slide deck too... [More]

Things I Learned While Teaching Java (part 2)
Nolan Erck said: I'm aware that it's in the Java spc, I just don't like it. I... [More]

CF Objective Recap and Highlights
Jason Dean said: Thanks, Nolan! [More]

CF Objective Notes - What's a Pull Request? (Contributing to Open Source)
Brad Wood said: Thanks for posting your notes! Here the full slide deck too... [More]

Things I Learned While Teaching Java (part 2)
Nolan Erck said: I'm aware that it's in the Java spc, I just don't like it. I... [More]



BlogCFC was created by Raymond Camden. This blog is running version 5.9.7. Contact Blog Owner