Bug 198560 – [Pointer Events] Fire pointerout and pointerleave events after firing pointercancel

• Status: RESOLVED
• Resolution: FIXED
• Component: UI Events

[Antoine Quint]

[Pointer Events] Fire pointerout and pointerleave events after firing pointercancel

[Antoine Quint]

Created attachment 371388 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 371388 [details]
Patch

Clearing flags on attachment: 371388

Committed r246122: <https://trac.webkit.org/changeset/246122>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/51451277>

[Darryl Noakes]

Was this actually released? It is still an issue for me on iOS 15.6.1 and iOS 16.

[Chris Dumez]

(In reply to Darryl Noakes from comment #5)
> Was this actually released? It is still an issue for me on iOS 15.6.1 and
> iOS 16.

That change is already and definitely shipped at some point in the past. If you're still experiencing issues, I recommend filing a new bug.

[Darryl Noakes]

Okay, will do.

I have investigated a little, and it is partially correct when listening for events on the element being manipulated.
However, manipulating a _child_ element does not fire the expected events.

[Darryl Noakes]

To clarify:

When listening for pointer events on an element, Chrome always fires `pointerleave` event on an element when `pointerleave` has been fired on a child element. Safari does this when tapping (as expected, as the pointer has been removed (https://www.w3.org/TR/pointerevents/#the-pointerleave-event)), but not when scrolling.

This may be due to different interpretations of the spec for `pointerleave` (https://www.w3.org/TR/pointerevents/#the-pointerleave-event), with Chrome taking the reasons for firing to include events on child elements and Safari not.

What is the expected behavior for `pointerleave`?

(Sorry for hijacking this thread. I do not currently have access to my test iPhone and so can't submit a proper report yet; if this is even something that needs one.)