Re: [pointerevents] Changing the DOM hierarchy while handling a "pointerenter" event produces significantly different results across browsers (#285)

I recently filled (what I found to be) a [bug](https://bugs.chromium.org/p/chromium/issues/detail?id=1147674#makechanges) on Chromium particularly related to this discussion (which I just found out about). It might be a good use case to watch for:

"It is a common practice to listen to "pointerenter" and "pointerleave" events to keep track of which pointers are currently "visible" on the screen, which works well for any kind of pointer device (mouse and touch, for instance). When a "pointerleave" event is ignored as a result of removing the target element from the DOM (which might be a common operation), the system will end up holding a bad state, incorrectly signaling the pointer is still visible forever."

The analogy with Mouse Events gets trickier when dealing with a device that "does not support hover". I believe the Pointer Events spec should include this case and advise for firing "pointerleave" following up "pointerup" as it is already expected for that kind of device, although it is not currently what is happening on flagship mobile browsers (I tested on Chrome for Android and Firefox for Android). At the very least, browsers should consider firing "pointercancel" when the target element is removed (which I would not find intuitive, but still workable), otherwise I wouldn't know a reliable way of keeping track of such state.

I hope this is helpful! @garykac

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


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

Received on Wednesday, 11 November 2020 03:28:55 UTC