This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Example: http://jsfiddle.net/dfreedm/wAHQm/ In this example, a non-bubbling event is fired on a child node of a ShadowRoot. An event listener on the ShadowRoot's Host will fire for this event. This seems counter-intuitive, because in regular DOM, the only element that will fire an event handler for such an event is the original target.
FYI, In Gecko's XBL1 non-bubbling events do propagate back to the binding parent (== host), but listeners added to bubble phase on anonymous content aren't triggered.
The interesting bit in the fiddle for me is that the listener is invoked at the AT_TARGET phase, and that seems reasonable, at least for bubbling events. For example, suppose a user clicks on a <video> element's play button, which is in a shadow tree. It seems that if the user also registered an event listener on <video>, they should hear this click at the AT_TARGET phase with <video> as target, since to the user, the whole <video> is an opaque thing. Things get murky when we start considering non-bubbling events. If a non-bubbling event like focus is fired on that same play button, should <video> invoke the corresponding listener at the AT_TARGET phase?
(In reply to comment #2) > The interesting bit in the fiddle for me is that the listener is invoked at > the AT_TARGET phase, and that seems reasonable, at least for bubbling events. > > For example, suppose a user clicks on a <video> element's play button, which > is in a shadow tree. It seems that if the user also registered an event > listener on <video>, they should hear this click at the AT_TARGET phase with > <video> as target, since to the user, the whole <video> is an opaque thing. > > Things get murky when we start considering non-bubbling events. If a > non-bubbling event like focus is fired on that same play button, should > <video> invoke the corresponding listener at the AT_TARGET phase? This is a good point. I think that you are correct that events like "focus" need to fire at the host as well. For any events that a developer does not want to "leak" out of the Shadow, they should set the stop propagation flag. Perhaps this note should be added to the spec?
I think there are actually two different use cases here: non-bubbling events sent by the platform (like focus and blur), and developer generated events fired through script (shadowedElement.dispatchEvent(new CustomEvent('foo', {bubbles: false}))). In the first case, it makes sense for the host to see these events, as this preserves the transparency of the ShadowRoot w.r.t. behaving like any other element. In the second case, it makes sense for the host to *not* see these events, as that seems like a leak in the encapsulation of the ShadowRoot. I can imagine developer defined shadows, or Custom Elements, that use a non-bubbling event as API. If this event would also fire on the host, a developers only recourse to prevent that is by using stopImmediatePropagation, which will prevent any other handlers at the shadowedElement for that event from firing.
(In reply to comment #4) > I think there are actually two different use cases here: non-bubbling events > sent by the platform (like focus and blur), and developer generated events > fired through script (shadowedElement.dispatchEvent(new CustomEvent('foo', > {bubbles: false}))). > > In the first case, it makes sense for the host to see these events, as this > preserves the transparency of the ShadowRoot w.r.t. behaving like any other > element. > > In the second case, it makes sense for the host to *not* see these events, > as that seems like a leak in the encapsulation of the ShadowRoot. I can > imagine developer defined shadows, or Custom Elements, that use a > non-bubbling event as API. If this event would also fire on the host, a > developers only recourse to prevent that is by using > stopImmediatePropagation, which will prevent any other handlers at the > shadowedElement for that event from firing. I think the second use case will be addressed by this: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0312.html
Closing this, since bug 20247 is where the work will be done. *** This bug has been marked as a duplicate of bug 20247 ***