This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Various HTML elements fire load and error events, but typically only once. Given the event retargetting behavior in Shadow DOM, when elements within a shadow subtree fire a load or error event (e.g. IMG), that event will propagate out and appear to be an event on the shadow host itself. This will happen for each piece of shadow content which fires such an event, giving the impression that the shadow host has reached a 'load' or 'error' state (or both!) multiple times. To avoid this, the load and error events should be added to the list of events which are stopped at the nearest shadow boundary.
This sounds reasonable.
http://dvcs.w3.org/hg/webcomponents/rev/90ec7ce72c4a
Let me reopen this. It sounds reasonabe, but there are some use cases that we must handle. When I tried to add 'load' and 'error' events to the 'stop' list, some layout tests in WebKit started to fail. One of them is a fast/dom/shadow/shadowdom-for-image-dynamic.html. We have some layout tests which depends on an assumption like the following: 1. <img> element, which will be a shadow host, has a 'onload' listener. 2. A user adds a shadow root to the <img> element. 3. The listener registered on the shadow host should still receive a 'load' event for the 'image'. So we will break the compatibility in this case.
(In reply to comment #3) > Let me reopen this. > > It sounds reasonabe, but there are some use cases that we must handle. > > When I tried to add 'load' and 'error' events to the 'stop' list, some layout > tests in WebKit started to fail. > One of them is a fast/dom/shadow/shadowdom-for-image-dynamic.html. > > We have some layout tests which depends on an assumption like the following: > 1. <img> element, which will be a shadow host, has a 'onload' listener. > 2. A user adds a shadow root to the <img> element. > 3. The listener registered on the shadow host should still receive a 'load' > event for the 'image'. > > So we will break the compatibility in this case. Yeah, I think this change will conflict to replaced elements spec. When considering Replaced Elements like <img>, it seems natural that 'load' event is fired on a special element in the shadow subtree of <img>, because an element in shadow subtree would like to handle 'load' event.
(In reply to comment #4) > (In reply to comment #3) > > Let me reopen this. > > > > It sounds reasonabe, but there are some use cases that we must handle. > > > > When I tried to add 'load' and 'error' events to the 'stop' list, some layout > > tests in WebKit started to fail. > > One of them is a fast/dom/shadow/shadowdom-for-image-dynamic.html. > > > > We have some layout tests which depends on an assumption like the following: > > 1. <img> element, which will be a shadow host, has a 'onload' listener. > > 2. A user adds a shadow root to the <img> element. > > 3. The listener registered on the shadow host should still receive a 'load' > > event for the 'image'. > > > > So we will break the compatibility in this case. > > Yeah, I think this change will conflict to replaced elements spec. > > When considering Replaced Elements like <img>, it seems natural that 'load' > event is fired on > a special element in the shadow subtree of <img>, because an element in shadow > subtree would like to > handle 'load' event. I am not sure which "replaced element spec" you're talking about and where will we break the compatibility? The fact that the special inner element is the one firing the load event is just an implementation detail (and an incorrect one, right?).
> I am not sure which "replaced element spec" you're talking about and where will > we break the compatibility? > > The fact that the special inner element is the one firing the load event is > just an implementation detail (and an incorrect one, right?). Yeah, it might be an implementation details. However, if the special inner element does not fire an event, how the elements in author shadow tree receives an event? Such elements cannot receive an event? I don't think this is a desired behavior...
(In reply to comment #6) > > I am not sure which "replaced element spec" you're talking about and where will > > we break the compatibility? > > > > The fact that the special inner element is the one firing the load event is > > just an implementation detail (and an incorrect one, right?). > > Yeah, it might be an implementation details. However, if the special inner > element does not fire an event, how the elements in author shadow tree receives > an event? Such elements cannot receive an event? I don't think this is a > desired behavior... They would just register a listener on the host? This is a very similar situation to VIDEO/AUDIO element implementation: the events fire on the element, and shadow DOM listens to them.
(In reply to comment #7) > (In reply to comment #6) > > > I am not sure which "replaced element spec" you're talking about and where will > > > we break the compatibility? > > > > > > The fact that the special inner element is the one firing the load event is > > > just an implementation detail (and an incorrect one, right?). > > > > Yeah, it might be an implementation details. However, if the special inner > > element does not fire an event, how the elements in author shadow tree receives > > an event? Such elements cannot receive an event? I don't think this is a > > desired behavior... > > They would just register a listener on the host? This is a very similar > situation to VIDEO/AUDIO element implementation: the events fire on the > element, and shadow DOM listens to them. Hmm... OK... You say that just adding an EventListener to the host is enough? Then we could handle it...
(In reply to comment #8) > Hmm... OK... > You say that just adding an EventListener to the host is enough? Then we could > handle it... Great!
I am lost. Could you guys explain what is concluded? 1. Users add a 'onload' listener on the <img> (or <video> element). 2. Users add a author shadow root to the <img> element. 3. Users set img.src = 'someurl'. In this case, will the listener receive an onload event? (In reply to comment #9) > (In reply to comment #8) > > > Hmm... OK... > > You say that just adding an EventListener to the host is enough? Then we could > > handle it... > > Great!
I understood. The current webkit implementation for <img> element is just wrong. A 'load' event in such case should be fired on the host element, not the element in the shadow dom subtree. (In reply to comment #10) > I am lost. Could you guys explain what is concluded? > > 1. Users add a 'onload' listener on the <img> (or <video> element). > 2. Users add a author shadow root to the <img> element. > 3. Users set img.src = 'someurl'. > > In this case, will the listener receive an onload event? > > > (In reply to comment #9) > > (In reply to comment #8) > > > > > Hmm... OK... > > > You say that just adding an EventListener to the host is enough? Then we could > > > handle it... > > > > Great!