event.stopPropagation() can allow event handlers registered on a different phase to still fire

RESOLVED INVALID

Status

()

Core
DOM: Events
RESOLVED INVALID
9 years ago
9 years ago

People

(Reporter: Russel Lindsay, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

Register 2 listeners on a link element. The first listener with capture phase, the second with bubbling phase. The capture event listener calls event.stopPropagation(). Now click the link - the bubble registered listener still fires! Now add a child node in the link (e.g. some bold text) and click the child node. Everything works correctly! The error only occurs when the eventPhase is '2', even though each event listener was registered as either capture (1) or bubble (3). I can understand still firing the capture phase listener, but calling the bubble phase registered one?

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
(Reporter)

Comment 1

9 years ago
Created attachment 342545 [details]
test page that allows you to see the bug

clicking on the text 'my outer link with an' fires both event listeners. clicking on the text 'inner bold element' fires only 1 event listener.
I made this mistake once upon a time.  The thing is, if you register an event listener on a given target, and the event fires at that target... it doesn't matter if you add it as capturing or bubbling.  Both will execute, because the event's at that given target.

Now, with stopPropagation, that doesn't mean the event won't hit the rest of the event listeners on that target.  From DOM 2 Events, section 1.2.2:

"If the capturing EventListener wishes to prevent further processing of the event from occurring it may call the stopProgagation method of the Event interface. This will prevent further dispatch of the event, although additional EventListeners registered at the same hierarchy level will still receive the event."

http://www.w3.org/TR/DOM-Level-2-Events/events.html
(Reporter)

Comment 3

9 years ago
Thanks Alex!

I think/hope I see now... I tried a simple experiment of adding a bubbled listener before a captured listener to the event target and fired the event on the same target. When the event fires the bubbled listener gets called first... which seems to me to indicate that all listeners on the target are being treated as if they were registered for the AT_TARGET phase, and normal order of listener addition applies. Previously I had considered the AT_TARGET phase more of a 'pretend' phase.

Though I must say that this behaviour is a little disturbing... I've always assumed that a capture listener would fire before a bubbled one, and that it could stop a bubble registered one. Now I know why it cant stop the listeners registered on the bubble phase - they might have already fired. eek!

cheers
Per comment 3, marking INVALID.  :)
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.