Bug 20247 - [Shadow]: Update constraints around stopping events
[Shadow]: Update constraints around stopping events
Status: NEW
Product: WebAppsWG
Classification: Unclassified
Component: Component Model
unspecified
PC All
: P2 normal
: ---
Assigned To: Dimitri Glazkov
public-webapps-bugzilla
:
: 20248 20633 21269 21400 (view as bug list)
Depends on:
Blocks: 28552 28564
  Show dependency treegraph
 
Reported: 2012-12-05 15:27 UTC by Dimitri Glazkov
Modified: 2015-04-27 08:26 UTC (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov 2012-12-05 15:27:41 UTC
"The following events must always be stopped at the nearest shadow boundary:"

Since we relaxed the lower boundary in regard to events, we should similarly not stop events there.
Comment 1 Dimitri Glazkov 2012-12-05 15:31:06 UTC
Also, this needs to account for the nodes, distributed to the insertion point. Events from those should be heard outside of the shadow tree.
Comment 2 Dimitri Glazkov 2012-12-05 17:54:57 UTC
And we need to write down the rationale behind stopping these events.
Comment 3 Dimitri Glazkov 2012-12-06 23:08:37 UTC
I am trying to come up with a general rule of thumb. I guess is something like:

If the event is retargeted, does event's meaning change?

For example, if a "load" event is heard at a shadow host, it conveys the meaning of shadow host somehow completing loading, which is not true, because all it means that some element inside of host's shadow tree has completed loading.

Conversely, if an "click" event is heard a a shadow host, it says that the shadow host was clicked. Since shadow tree is how shadow host is rendered, the meaning of the event stays the same.

WDYT?
Comment 4 Anne 2012-12-07 10:50:53 UTC
But if the shadow tree actually did load something via XMLHttpRequest and wanted to convey that you're lost.

I suppose the current set of events is based on what WebKit needed? It seems unclear that will match the needs of developers when this gets out in the wild.
Comment 5 Dimitri Glazkov 2012-12-07 16:42:25 UTC
(In reply to comment #4)
> But if the shadow tree actually did load something via XMLHttpRequest and
> wanted to convey that you're lost.

Then just fire a "load" event on the shadow host?

> 
> I suppose the current set of events is based on what WebKit needed? It seems
> unclear that will match the needs of developers when this gets out in the
> wild.

We only wanted to stop a "selectstart" in WebKit. The rest of the list is based on Microsoft's experience with HTC:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15804
Comment 6 Dimitri Glazkov 2012-12-07 23:58:17 UTC
From a thread on whatwg: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-December/038283.html

>It sounds though like you'd want a different approach to this. What if
>I have a <video> as my implementation detail?

Then you probably don't want the "load" events of <video> escaping out of the shadow tree, just as the spec provides.

It's an interesting question, though. Along with "load", such implementation detail may dispatch a whole bunch of other events (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#mediaevents).

Most of these events--at least, following my reasoning--seem like they should just be kept in the shadow tree.

I wonder if we would be better off reversing the condition and stopping ALL events, except a set of events whose meaning stays clear after retargeting (like "click").
Comment 7 Dimitri Glazkov 2012-12-07 23:59:22 UTC
*** Bug 20248 has been marked as a duplicate of this bug. ***
Comment 8 Dimitri Glazkov 2013-04-01 23:21:07 UTC
Also interesting comments in bug 20633.
Comment 9 Dimitri Glazkov 2013-04-01 23:21:12 UTC
*** Bug 20633 has been marked as a duplicate of this bug. ***
Comment 10 Anne 2013-04-02 08:29:11 UTC
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg312 is how we should solve this imo.
Comment 11 Dimitri Glazkov 2013-05-08 17:44:43 UTC
Bug 21269 has a great discussion around use cases to arbitrarily control event stopping.
Comment 12 Dimitri Glazkov 2013-05-08 17:45:13 UTC
*** Bug 21269 has been marked as a duplicate of this bug. ***
Comment 13 Dimitri Glazkov 2013-07-17 22:02:55 UTC
*** Bug 21400 has been marked as a duplicate of this bug. ***
Comment 14 Steve Orvell 2013-09-26 00:25:33 UTC
A polymer user had a question about this today which prompted some discussion (www.polymer-project.org).

I think at the least the spec needs to be updated to explain the logic behind stopping events. Most of the events that are stopped are non-bubbling events (except 'change'). Since these don't bubble, why must they be stopped? Is this to prevent capturing?

Stopping events poses some problems:

1. Are the events stopped entirely by name? For example, if a synthetic event is dispatched called 'load' will it be stopped? If so, that seems bad.

2. In the context of custom elements, the developer may want control over whether or not the event stops at the shadowDOM boundary.

In light of this complexity, it seems like a more complex api would be needed to be able to hide shadow events effectively.

Instead of introducing this complexity, perhaps we can remove the concept of stopped events entirely and instead rely on bubbling behavior. Non-bubbling events will naturally not propagate outside shadowRoot. Events that are captured would just be retargeted.
Comment 15 Hayato Ito 2015-02-13 08:28:28 UTC
I've added a like to this issue to the spec:

https://github.com/w3c/webcomponents/commit/aa322cb29c114f2886264e565043874996705aeb
Comment 16 Hayato Ito 2015-02-13 08:29:01 UTC
(In reply to Hayato Ito from comment #15)
> I've added a like to this issue to the spec:
> 
> https://github.com/w3c/webcomponents/commit/
> aa322cb29c114f2886264e565043874996705aeb

s/like/link/.
Comment 17 Anne 2015-04-23 18:43:53 UTC
The solution here is to add a bit flag to the event dispatch algorithm whether or not the event needs to be scoped to the shadow tree. And then set it in specifications from all the relevant features, such as e.g. <img>'s load & error events.