deepPath's definition is ambiguous when the event path contains a non-Node EventTarget

[rniwa]

We should clarify what happens when an event is fired on an XHR object, etc... Are we going to include all those items in the path that are not Node? Or does path only contain nodes?

[rniwa]

In particular, what happens if the path included a Node but the current target wasn't a Node? If such a situation can arise, then we can't determine whether a Node should be unclosed or not.

If such a situation can arise, I think returning an empty array when the current target is not a Node makes most sense. In fact, most of non-Node targets don't have anything to bubble up (e.g. XHR; is there any?) so there might not be any use case for deepPath() anyway.

[rniwa]

@annevk @travisleithead : I need your expertise in events.

[rniwa]

Talked with @annevk on IRC.

Apparently, hit regions within a canvas element are non-Node event targets, and the event path for them include canvas element and its ancestors, so this is the case for which the current definition is inadequate.

My proposal is to find the first Node event target parent from the current event target, and use that to filter nodes. If there are no such target, don't filter anything (e.g. for events on XHR).

[annevk]

Yeah, the current definition is incorrect in that it talks about nodes.

Also, what happens if you dispatch a node in a closed shadow tree that might be retargeted, it would be weird for the event path to only contain nodes of the light tree.

[hayatoito]

Yeah, we should consider a case where an event target is not a Node.

We should revise the following sentance:

Let PATH contain only a node which is an unclosed node of the current target of EVENT.

My rough idea is:

Give A, an event target in the event path, and B, the current target of EVENT:

• If A and B are both Node objects, nothing changes. The current definition should work.
• Otherwise, if A can be reached by repeatedly applying get the parent to B, or vice verse, include A in the deepPath().

Does this sound good?

Also, what happens if you dispatch a node in a closed shadow tree that might be retargeted, it would be weird for the event path to only contain nodes of the light tree.

This is an intentional behavior. Why do you think this is weird?

[hayatoito]

My proposal is to find the first Node event target parent from the current event target, and use that to filter nodes. If there are no such target, don't filter anything (e.g. for events on XHR).

Ops. I did not notice this proposal. Let me think about this...

[hayatoito]

Okay. Given an event target A (in the event path) and an event target B (as event's current target):

1. Let ANCESTOR-A be the nearest inclusive ancestor (in the event path) Node of A
2. Let ANCESTOR-B be the nearest inclusive ancestor (in the event path) Node of B
3. If both ANCESTOR-A and ANCESTOR-B exist, let's apply "unclosed node" check for them
4. Otherwise, do not filter A (Include A in deepPath())

Does this sound good?

[annevk]

@hayatoito if I have an event listener in a closed shadow tree, should I not get the actual event path?

[hayatoito]

You get. The value returned from event.deepPath() depends on the event's currentTarget. In such a case, while the event is being dispatched in the closed shadow tree, event.deepPath() will includes nodes in the closed shadow tree. Once the event gets out of the closed shadow tree, event.deepPath() will not return nodes in the closed shadow tree.

[annevk]

Okay, that matches my understanding, but in that case the "unclosed node" check seems wrong, since it should only apply to children of a hosted tree, not the current tree or the node's shadow-including inclusive ancestors.

[hayatoito]

Do you mean the following is wrong?

If both ANCESTOR-A and ANCESTOR-B exist, let's apply "unclosed node" check for them

Using ANCESTOR-A and ANCESTOR-B sounds bad here?
I am not sure 100% how this works. This is just the result of the clarification of @rniwa 's proposal (as far as my understanding is correct):

My proposal is to find the first Node event target parent from the current event target, and use that to filter nodes. If there are no such target, don't filter anything (e.g. for events on XHR).

[annevk]

It's not really clear to me how your algorithm works, since there's only one event path. The event path once computed is also a simple list, so we'd have to check if it contains a node I think. We can't talk about ancestors.

[hayatoito]

I see. Sorry for the confusion. I should not have used a terminology of an ancestor here.

By (inclusive) ANCESTOR, I meant it has a positional index which is less than or equal to A, in the ordered list (which is the event path).

[annevk]

Still, that doesn't explain how you have two event paths.

[hayatoito]

I have clarified it in the spec.

[annevk]

Since April 4 I learned that hit regions are not implemented yet and we'll likely change their design. Given that, we should probably revert this complexity and note somewhere we would need something like this if we ever mix node and non-node targets.