This function (http://www.w3.org/TR/DOM-Level-3-Events/#events-event-type-stopImmediatePropagation ) is implemented in Chrome, Safari and IE9 (according to http://samples.msdn.microsoft.com/ietestcenter/#webapps ) but still lacks in Firefox. It can be useful to ensure security (make sure that only the event handler you decided run, for instance).
(In reply to David Bruant from comment #0)
> (make sure that
> only the event handler you decided run, for instance).
It can't ensure that. There can be listeners in the list before your listener.
(In reply to Olli Pettay [:smaug] from comment #1)
> (In reply to David Bruant from comment #0)
> > (make sure that
> > only the event handler you decided run, for instance).
> It can't ensure that. There can be listeners in the list before your
True. I meant "under the condition that you run first".
Created attachment 571467 [details] [diff] [review]
the interesting part is in the beginning. Rest is mainly just (automatic) uuid changes.
Uploaded to tryserver.
Note, the patch gives IE9/DOM4 behavior. Webkit does something a bit different with the flags,
and I haven't understood what Opera does.
Or, hmm, does IE9 still do something else. I need to test.
So, IE9 clears propagation flags after dispatching an event.
Gecko kinds of does that also atm (unless system group listener calls stopPropagation, but that is a bug.)
I think IE9's behavior is better than what DOM4 says (and no one implements that part of DOM4 correctly anyway).
Created attachment 571648 [details] [diff] [review]
Simpler, and keeps more of the old behavior, and IE9 seems to behave this way.
(I'll file spec bugs)
Created attachment 572013 [details] [diff] [review]
(In reply to Olli Pettay [:smaug] from comment #7)
> (I'll file spec bugs)
Did you? Where can i follow progress on that?
Sorry, I haven't filed them yet. I need to re-review DOM4's event handling fully, since it seems
to have some minor problems there and there. (D3E kind of don't have those problems, I think,
because it leaves some cases undefined.)