Re: [pointerevents] Clarify `pointerleave` and `pointerout` events when first pointer move after removing an element under the pointer (#477)

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](https://github.com/web-platform-tests/interop/issues/380) for the detail.

Hmm, I added this test to match the expectation in a user reported [Chrome bug](https://crbug.com/1147998).  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](https://w3c.github.io/uievents/#events-mouseevent-event-order) 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](https://dom.spec.whatwg.org/#concept-event-dispatch) 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](https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/core/input/pointer_event_manager.cc;drc=a742c65cc620d2b7b262b5514540ebdb510a7121;l=291) store all elements, instead keeps track of the last known "element under pointer" then infers about exited/enter elements using the [common ancestor](https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/core/input/boundary_event_dispatcher.cc;drc=a742c65cc620d2b7b262b5514540ebdb510a7121;l=58) 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".

-- 
GitHub Notification of comment by mustaqahmed
Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/477#issuecomment-1650127159 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 25 July 2023 16:07:34 UTC