Clarify `pointerleave` and `pointerout` events when first pointer move after removing an element under the pointer #477

masayuki-nakano · 2023-07-21T00:42:54Z

I worked on fixing the failure in Firefox of pointerevent_after_target_removed.html. However, its expectation does not make sense. See web-platform-tests/interop#380 for the detail.

The main issue is, the spec does not define pointerleave and pointerout should be fired on which element(s) or should not be fired at the first move after an element under the pointer is removed.

Some definitions indicate that pointerleave, pointerout, pointerenter and pointerover should not be fired immediately (without a pointer move) when an element under the pointer is removed by a DOM API or hidden/moved by a style change. Then, web apps may want to listen to pointerleave and pointerout at next pointer move to clear something set at pointerenter or pointerover.

The spec does not disallow to dispatch pointerout on removed element (which is the last pointerover'ed element). Safari does that, and it seems reasonable.

The big problem here is, pointerleave. pointerenter must have been fired on the removed element and its ancestors. From web apps point of view, pointerleave should be fired on all elements which pointerenter was fired on and are not ancestors of the element currently under the pointer. However, it sounds like terrible. To do that, browsers need to store all elements which the browser dispatched pointerenter, but this means that nearly root ancestors will be stored for a long time, e.g., the <body> element. And the dispatching code becomes complicated because DOM API may remove only some ancestors with re-connecting an ancestor to the same point.

@EdgarChen, @smaug----

The text was updated successfully, but these errors were encountered:

mustaqahmed · 2023-07-25T16:07:31Z

Below are my comments/questions to aid the discussion:

I worked on fixing the failure in Firefox of pointerevent_after_target_removed.html. However, its expectation does not make sense. See web-platform-tests/interop#380 for the detail.

Hmm, I added this test to match the expectation in a user reported Chrome bug. I haven't looked into all the details you mentioned above, but I can see that pointerover/out events were not mentioned in the Chrome bug, so I need to check if I accidentally made the test an "overfit"!

The main issue is, the spec does not define pointerleave and pointerout should be fired on which element(s) or should not be fired at the first move after an element under the pointer is removed.

Yes, and one reason is that the text in PointerEvents depends on the hand-wavy definition in UI Event Spec.

Some definitions indicate that pointerleave, pointerout, pointerenter and pointerover should not be fired immediately (without a pointer move) when an element under the pointer is removed by a DOM API or hidden/moved by a style change. Then, web apps may want to listen to pointerleave and pointerout at next pointer move to clear something set at pointerenter or pointerover.

The spec does not disallow to dispatch pointerout on removed element (which is the last pointerover'ed element). Safari does that, and it seems reasonable.

After the element is removed from DOM, my quick read of DOM event dispatch algorithm suggests that the algorithm shouldn't do anything at least because event.eventPhase becomes undefined in that case. The algorithm is a bit complicated, so please correct me if I missed anything here (which is very likely).

One question is: does WebKit dispatch the pointerout event right before the element is removed (and before any further physical movement of the pointer)?

The big problem here is, pointerleave. pointerenter must have been fired on the removed element and its ancestors. From web apps point of view, pointerleave should be fired on all elements which pointerenter was fired on and are not ancestors of the element currently under the pointer. However, it sounds like terrible. To do that, browsers need to store all elements which the browser dispatched pointerenter, but this means that nearly root ancestors will be stored for a long time, e.g., the <body> element. And the dispatching code becomes complicated because DOM API may remove only some ancestors with re-connecting an ancestor to the same point.

@EdgarChen, @smaug----

Chrome does not store all elements, instead keeps track of the last known "element under pointer" then infers about exited/enter elements using the common ancestor of previous vs current "element under pointer" in the current DOM. The big comment in the common ancestor code implies it's a legacy Chrome behavior to "match Firefox and IE".

masayuki-nakano · 2023-07-26T01:22:17Z

I worked on fixing the failure in Firefox of pointerevent_after_target_removed.html. However, its expectation does not make sense. See web-platform-tests/interop#380 for the detail.

Hmm, I added this test to match the expectation in a user reported Chrome bug. I haven't looked into all the details you mentioned above, but I can see that pointerover/out events were not mentioned in the Chrome bug, so I need to check if I accidentally made the test an "overfit"!

The test expects that same kind of events are dispatched with same event order between mouse events and pointer events.

Historically, mouseout and mouseleave are fired when the element under the mouse cursor is removed/moved. This is defined as:

A user agent MUST dispatch this event when a pointing device is moved off of the boundaries of an element or when the element is moved to be no longer underneath the primary pointing device.

On the other hand, pointerout and poinerleave does not have the similar definition and this issue clearly indicates that browsers should not dispatch the events until the pointer is moved.

I.e., they are fired in the different rules, but the test expects same result between mouse events and pointer events.

Some definitions indicate that pointerleave, pointerout, pointerenter and pointerover should not be fired immediately (without a pointer move) when an element under the pointer is removed by a DOM API or hidden/moved by a style change. Then, web apps may want to listen to pointerleave and pointerout at next pointer move to clear something set at pointerenter or pointerover.
The spec does not disallow to dispatch pointerout on removed element (which is the last pointerover'ed element). Safari does that, and it seems reasonable.

After the element is removed from DOM, my quick read of DOM event dispatch algorithm suggests that the algorithm shouldn't do anything at least because event.eventPhase becomes undefined in that case. The algorithm is a bit complicated, so please correct me if I missed anything here (which is very likely).

I think that it's fine to dispatch DOM events in a document fragment. An orphan node can be treated as the root element of a document fragment. Then, event phase can be set as same as when the node is in the owner document. (I.e., if browsers dispatch a DOM event on an orphan node, only the target phase will appear.)

One question is: does WebKit dispatch the pointerout event right before the element is removed (and before any further physical movement of the pointer)?

According to the test result (only pointerenter is fired on the (ex-)parent), Safari dispatches pointerout after the node is removed (and probably at moving the pointer).

Chrome does not store all elements, instead keeps track of the last known "element under pointer" then infers about exited/enter elements using the common ancestor of previous vs current "element under pointer" in the current DOM. The big comment in the common ancestor code implies it's a legacy Chrome behavior to "match Firefox and IE".

Firefox does similar thing. Firefox stores both elements under the cursor which are targeted by mouseover and pointerover and compute ancestors to dispatch *leave events at dispatch. Therefore, once the DOM tree is changed from *enter events, elements may be targeted only by *leave or *enter.

I think that Chrome dispatches pointerout and pointerover immediately if the element under the pointer is removed. Therefore, reset the storage and store new elements under the pointer within the new DOM tree.

flackr · 2023-08-19T01:21:42Z

I left my recommendation in web-platform-tests/interop#380 (comment)

TLDR, i think that on node removal we should track the nearest still attached node as the one the pointer is over. This will result in correct pointer counts when we subsequently dispatch boundary events.

patrickhlauke · 2023-09-14T15:21:42Z

Decided during PEWG meeting at TPAC: Leaving this issue open until we have at least one browser that includes the proposed fix/behaviour

mustaqahmed · 2023-10-11T15:16:04Z

We still need WPTs around shadow-DOM boundary and slot elements.

smaug---- · 2023-10-11T15:20:56Z

For Shadow DOM if the removed node is topmost element in Shadow DOM, we probably want to find the nearest shadow-including inclusive ancestor Element, and otherwise just find parent the same way how event path would find a "parent".'

Or should we rely on event path?

flackr · 2023-10-25T15:40:14Z

It looks like step dispatching events defines how the event path is constructed. In the case of node removal we don't have a current event so we should follow the algorithm there for finding the nearest still attached parent that would be in the event path.

This explains how the previous target is tracked when the previous target is removed from the DOM for w3c#477.

flackr · 2023-11-09T21:37:34Z

While reviewing the fix @mustaqahmed is working on, I also discovered that when we remove nodes during the dispatch of boundary events we still send events to the removed nodes.

E.g. load https://jsbin.com/rawogov/edit?html,css,js,output and move the mouse from the blue box up. The green removed box still gets an event.

I think this is also in violation of the ui-events section which states:

If the event target (e.g. the target element) is removed from the DOM during the mouse events sequence, the remaining events of the sequence MUST NOT be fired on that element.

mustaqahmed · 2023-11-10T16:44:32Z

Thanks for pointing out the violation of the spec. Chrome had an old comment to investigate its boundary event dispatch algorithm, see the bug we just filed.

…#491) * Explain how a removed DOM node should be handled for boundary events. This explains how the previous target is tracked when the previous target is removed from the DOM for #477. * Use a more specific needs over event flag.

patrickhlauke · 2023-12-06T16:20:53Z

Closing, just needs WPT

patrickhlauke · 2023-12-06T16:22:15Z

From @mustaqahmed

Chrome supports this behavior now as an experimental web platform feature, so we now have one impl technically.

mustaqahmed · 2024-02-14T16:26:35Z

Looks like @masayuki-nakano addded this WPT to cover the shadow-dom case: https://github.com/web-platform-tests/wpt/blob/master/pointerevents/pointerevent_pointer_boundary_events_after_removing_last_over_element.html

We still need a WPT for slot elements.

smaug---- · 2024-04-10T15:24:29Z

@masayuki-nakano would it be easy to just tweak those tests a tiny bit to cover also slots?

masayuki-nakano · 2024-04-11T05:27:51Z

@masayuki-nakano would it be easy to just tweak those tests a tiny bit to cover also slots?

Yeah, I think so, but could you clarify what cases do you want?

smaug---- · 2024-04-11T08:12:19Z

I guess there should be tests for removing an assigned node (so removing a light DOM node, which is assigned to a slot), and also test a case where slot has assigned nodes and then the slot itself is removed from shadow DOM.

masayuki-nakano · 2024-05-14T06:59:12Z

Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1896552

This CL adds tests for two untested aspects of PointerEvents in slots: - PE event sequence around slots when the shadow DOM remains unchanged. - Boundary events after modifications to slotted elements. This covers the last remaining WPT for: w3c/pointerevents#477 Bug: 40156858 Change-Id: I9823595a0b15672d0395d4e117ccc6462c3e42f2

This CL adds tests for two untested aspects of PointerEvents in slots: - PE event sequence around slots when the shadow DOM remains unchanged. - Boundary events after modifications to slotted elements. This covers the last remaining WPT for: w3c/pointerevents#477 Bug: 40156858 Change-Id: I9823595a0b15672d0395d4e117ccc6462c3e42f2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5598510 Commit-Queue: Mustaq Ahmed <[email protected]> Reviewed-by: Robert Flack <[email protected]> Cr-Commit-Position: refs/heads/main@{#1313570}

mustaqahmed · 2024-06-11T19:18:44Z

Done landing WPTs for slotted elements: web-platform-tests/wpt#46694

Related to: w3c/pointerevents#477 Bug: 40156858 Change-Id: Ia7b952a48b89a6d932a3a4d71f36e8086d261c48

Related to: w3c/pointerevents#477 Bug: 40156858 Change-Id: Ia7b952a48b89a6d932a3a4d71f36e8086d261c48 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5622053 Commit-Queue: Mustaq Ahmed <[email protected]> Reviewed-by: Robert Flack <[email protected]> Cr-Commit-Position: refs/heads/main@{#1313946}

…ted elements., a=testonly Automatic update from web-platform-tests WPT coverage for Pointer Events for slotted elements. This CL adds tests for two untested aspects of PointerEvents in slots: - PE event sequence around slots when the shadow DOM remains unchanged. - Boundary events after modifications to slotted elements. This covers the last remaining WPT for: w3c/pointerevents#477 Bug: 40156858 Change-Id: I9823595a0b15672d0395d4e117ccc6462c3e42f2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5598510 Commit-Queue: Mustaq Ahmed <[email protected]> Reviewed-by: Robert Flack <[email protected]> Cr-Commit-Position: refs/heads/main@{#1313570} -- wpt-commits: b8aab6837b61aacee4cbad1fbb6aeb3952af7b60 wpt-pr: 46694

…ted elements., a=testonly Automatic update from web-platform-tests WPT coverage for Pointer Events for slotted elements. This CL adds tests for two untested aspects of PointerEvents in slots: - PE event sequence around slots when the shadow DOM remains unchanged. - Boundary events after modifications to slotted elements. This covers the last remaining WPT for: w3c/pointerevents#477 Bug: 40156858 Change-Id: I9823595a0b15672d0395d4e117ccc6462c3e42f2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5598510 Commit-Queue: Mustaq Ahmed <mustaqchromium.org> Reviewed-by: Robert Flack <flackrchromium.org> Cr-Commit-Position: refs/heads/main{#1313570} -- wpt-commits: b8aab6837b61aacee4cbad1fbb6aeb3952af7b60 wpt-pr: 46694 UltraBlame original commit: 60779ff43603360d82107deb6ca1cd519fa169d8

…to shadow-host and slot, a=testonly Automatic update from web-platform-tests PointerEvent WPT: add checks for events to shadow-host and slot Related to: w3c/pointerevents#477 Bug: 40156858 Change-Id: Ia7b952a48b89a6d932a3a4d71f36e8086d261c48 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5622053 Commit-Queue: Mustaq Ahmed <[email protected]> Reviewed-by: Robert Flack <[email protected]> Cr-Commit-Position: refs/heads/main@{#1313946} -- wpt-commits: a3831b7add5dc42c1daf38a93e827710f8839576 wpt-pr: 46697

…to shadow-host and slot, a=testonly Automatic update from web-platform-tests PointerEvent WPT: add checks for events to shadow-host and slot Related to: w3c/pointerevents#477 Bug: 40156858 Change-Id: Ia7b952a48b89a6d932a3a4d71f36e8086d261c48 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5622053 Commit-Queue: Mustaq Ahmed <mustaqchromium.org> Reviewed-by: Robert Flack <flackrchromium.org> Cr-Commit-Position: refs/heads/main{#1313946} -- wpt-commits: a3831b7add5dc42c1daf38a93e827710f8839576 wpt-pr: 46697 UltraBlame original commit: 828793bbbe3b5a092eddaa5191a34d2c818deb35

…to shadow-host and slot, a=testonly Automatic update from web-platform-tests PointerEvent WPT: add checks for events to shadow-host and slot Related to: w3c/pointerevents#477 Bug: 40156858 Change-Id: Ia7b952a48b89a6d932a3a4d71f36e8086d261c48 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5622053 Commit-Queue: Mustaq Ahmed <[email protected]> Reviewed-by: Robert Flack <[email protected]> Cr-Commit-Position: refs/heads/main@{#1313946} -- wpt-commits: a3831b7add5dc42c1daf38a93e827710f8839576 wpt-pr: 46697

patrickhlauke added v3-blocking v3 labels Aug 15, 2023

mustaqahmed added the needs-wpt Investigation whether the issue needs a wpt test has been done and wpt is missing label Oct 11, 2023

flackr added a commit to flackr/pointerevents that referenced this issue Oct 31, 2023

Explain how a removed DOM node should be handled for boundary events.

fd853ba

This explains how the previous target is tracked when the previous target is removed from the DOM for w3c#477.

flackr mentioned this issue Oct 31, 2023

Explain how a removed DOM node should be handled for boundary events. #491

Merged

patrickhlauke closed this as completed Dec 6, 2023

masayuki-nakano mentioned this issue Feb 13, 2024

The expectation of pointerevent_after_target_removed.html does not match the spec web-platform-tests/interop#380

Closed

mustaqahmed self-assigned this May 24, 2024

chromium-wpt-export-bot mentioned this issue Jun 11, 2024

WPT coverage for Pointer Events for slotted elements. web-platform-tests/wpt#46694

Merged

mustaqahmed removed the needs-wpt Investigation whether the issue needs a wpt test has been done and wpt is missing label Jun 11, 2024

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 11, 2024

PointerEvent WPT: add checks for events to shadow-host and slot

60f6c59

Related to: w3c/pointerevents#477 Bug: 40156858 Change-Id: Ia7b952a48b89a6d932a3a4d71f36e8086d261c48

chromium-wpt-export-bot mentioned this issue Jun 11, 2024

PointerEvent WPT: add checks for events to shadow-host and slot web-platform-tests/wpt#46697

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify `pointerleave` and `pointerout` events when first pointer move after removing an element under the pointer #477

Clarify `pointerleave` and `pointerout` events when first pointer move after removing an element under the pointer #477

masayuki-nakano commented Jul 21, 2023

mustaqahmed commented Jul 25, 2023

masayuki-nakano commented Jul 26, 2023

flackr commented Aug 19, 2023

patrickhlauke commented Sep 14, 2023 •

edited

Loading

mustaqahmed commented Oct 11, 2023

smaug---- commented Oct 11, 2023 •

edited

Loading

flackr commented Oct 25, 2023

flackr commented Nov 9, 2023

mustaqahmed commented Nov 10, 2023

patrickhlauke commented Dec 6, 2023

patrickhlauke commented Dec 6, 2023

mustaqahmed commented Feb 14, 2024

smaug---- commented Apr 10, 2024

masayuki-nakano commented Apr 11, 2024

smaug---- commented Apr 11, 2024

masayuki-nakano commented May 14, 2024

mustaqahmed commented Jun 11, 2024

Clarify pointerleave and pointerout events when first pointer move after removing an element under the pointer #477

Clarify pointerleave and pointerout events when first pointer move after removing an element under the pointer #477

Comments

masayuki-nakano commented Jul 21, 2023

mustaqahmed commented Jul 25, 2023

masayuki-nakano commented Jul 26, 2023

flackr commented Aug 19, 2023

patrickhlauke commented Sep 14, 2023 • edited Loading

mustaqahmed commented Oct 11, 2023

smaug---- commented Oct 11, 2023 • edited Loading

flackr commented Oct 25, 2023

flackr commented Nov 9, 2023

mustaqahmed commented Nov 10, 2023

patrickhlauke commented Dec 6, 2023

patrickhlauke commented Dec 6, 2023

mustaqahmed commented Feb 14, 2024

smaug---- commented Apr 10, 2024

masayuki-nakano commented Apr 11, 2024

smaug---- commented Apr 11, 2024

masayuki-nakano commented May 14, 2024

mustaqahmed commented Jun 11, 2024

Clarify `pointerleave` and `pointerout` events when first pointer move after removing an element under the pointer #477

Clarify `pointerleave` and `pointerout` events when first pointer move after removing an element under the pointer #477

patrickhlauke commented Sep 14, 2023 •

edited

Loading

smaug---- commented Oct 11, 2023 •

edited

Loading