New issue
Advanced search Search tips

Issue 608003 link

Starred by 2 users
Status: Fixed
Owner:
nzolghadr@chromium.org
Closed: May 2016
Cc:
nzolghadr@chromium.org
rbyers@chromium.org
mustaq@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocking:
issue 471824
issue 609839



Sign in to add a comment

PointerEvents: Firing MEs correctly after PE handler removes its target

Project Member Reported by mustaq@chromium.org, Apr 29 2016 
Currently we fire the compat MouseEvent for a PointerEvent to the target of the PE. This correct as long as the PE handler doesn't delete the target node. The spec defines the ME's target to be the nearest "live" ancestor:

> Unless otherwise noted, the target of any mapped mouse event should be
> the same target as the respective pointer event unless the target is no 
> longer participating in its ownerDocument's tree. In this case, the
> mouse event should be fired at the original target's nearest ancestor
> node (at the time it was removed from the tree) that still participates 
> in its ownerDocument's tree, meaning that a new event path (based on
> the new target node) is built for the mouse event.

We need to fix this, add a test, and check Edge behavior.

Thanks Rick for catching this.

Comment 1 by mustaq@chromium.org, Apr 29 2016

Blocking: 471824
Owner: nzolghadr@chromium.org
Status: Assigned (was: Available)
Navid, could you please look into this?

Comment 2 by nzolghadr@chromium.org, Apr 29 2016 

Sure.

Comment 3 by nzolghadr@chromium.org, May 2 2016 

What if the pointer event handler first re-parent the node and then removes it? In that case even building the parent tree before pointer event handler would not help. Right?

Comment 4 by mustaq@chromium.org, May 2 2016 

My interpretation of the spec above is that suppressing MEs on deleted node is all we need. Re-parented would still get MEs as if this _was_ the state before firing the PE.

What does Edge do?

Comment 5 by nzolghadr@chromium.org, May 3 2016 

I don't think that's what spec means. What I understand from the spec is retargeting the event to the first parent of the element when it belonged to the document before removing. So if it gets reparented and then removed I expected the new parent gets the mousedown targeted at itself.

However, what Edge does is retargeting the mousedown to the parent node of the removed element before calling the pointerdown handler. Essentially it ignores the reparenting behavior there.

Comment 6 by mustaq@chromium.org, May 3 2016 

In #4, I used "suppressing" to emphasize not sending MEs to an orphan node. I took the "retargeting" as the obvious outcome of the current spec wording, sorry for being too concise.

I agree that the last quoted line from the spec in #0 above ("a new event path ... is built for the mouse event") is the troubling point. Without it, we would treat compat mouse propagation path to be the same as PE propagation path for optimization, and easily match Edge.

Whichever way the spec clarifies it, in reality there would always be a way to tweak the DOM to break the spec wording. We shouldn't worry to much about such cases, and keep the spec wording simple to match existing implementations.

So, I am inclined to redefining compat ME propagation path as the PE propagation path in the PE spec. Let's go for a pull request to draw the attention of the WG, specially the Edge engineers. If they don't like it, both Edge and us will go for a new (non-optimized) implementation.

Comment 7 by mustaq@chromium.org, May 6 2016

Blocking: 609839

Comment 9 by nzolghadr@chromium.org, May 9 2016

Status: Fixed (was: Assigned)
►

Sign in to add a comment