Note that there is another bug on .path open somewhere. It should be able to hold more than nodes.

(In reply to Anne from comment #1)
> Note that there is another bug on .path open somewhere. It should be able to
> hold more than nodes.

Yep. IIRC, event.path should return an array of *EventTarget*, rather than NodeList.

Correct. Domenic, event.path is another property where we want a "JavaScript Array" solution quickly.

I think at the TAG we were fairly strongly on the side of just using normal mutable JavaScript arrays. This shouldn't be hard.

To be clear I thought we also wanted to remove the retargetting that is done on the event path.

Composed tree

    a
    |
    b
    |
  [SR]
    |
    c
    |      
<content>
    |
    d

var calls = 0;
a.addEventListener('click', (e) => {
  assert.deepEqual([a, b, SR, c, content, d], e.path);
  calls++;
});
d.click();
assert.equal(calls, 1);

Erik, if event.path works like that, it does not describe what happens for elements existing today as they hide the shadow tree. Do we really want to leak shadow trees all over the place?

The idea would be to hide those from the path once the spec adds a way to make hidden shadow trees.

In Blink we would of course need to hide our internals for <video> etc even if the spec does not cover this yet.

Hmm. http://w3c.github.io/webcomponents/spec/shadow/#events-that-are-always-stopped is still around too. Those magic lists are bad. How is this shipping without the bugs filed being addressed?

(In reply to Anne from comment #8)
> Hmm.
> http://w3c.github.io/webcomponents/spec/shadow/#events-that-are-always-
> stopped is still around too. Those magic lists are bad. How is this shipping
> without the bugs filed being addressed?

Not sure what you mean there. There's both a bug for it (https://www.w3.org/Bugs/Public/show_bug.cgi?id=20247) and an explicit item in the plan thing I sent out early this year (http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0338.html)

(In reply to Erik Arvidsson from comment #5)
> To be clear I thought we also wanted to remove the retargetting that is done
> on the event path.

This could be filed as another issue.

Could you file another bug? I'd like to see a use case for that there.

I'd like to move this issue forward.

Can we agree on this?

AFAIR, we have a reason for this change. I appreciate someone would give us a use case for this change in this discussion.

a common pattern of event delegation is to put the delegate (listener) on the document root, but to mark specific nodes in the document which information about what to do with the specific event. When the delegate handles the event, it must inspect the node to retrieve the information (e.g. what method to invoke on the delegate). 

If the event.path is sanitized on it's way up as the event bubbles, in the information the document-wide delegate may need is no longer reachable because it belongs to the a node which has been removed.

However, if shadow tree nodes are just in there, it really isn't much of a "shadow" tree anymore, much more like a real tree. But I guess we lost that when we lost stronger encapsulation...

(In reply to Anne from comment #13)
> However, if shadow tree nodes are just in there, it really isn't much of a
> "shadow" tree anymore, much more like a real tree. But I guess we lost that
> when we lost stronger encapsulation...

Yup. Let's not forget to erase nodes from event path for "closed" shadow trees.

Thank you for the comments.

Let me update the spec so that event.path will return every nodes, except for nodes in the *closed descendant trees*.

Done at
https://github.com/w3c/webcomponents/commit/2a44fb1a32a3a6aaa7bd82d37f6bd17eb2d67535