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

Sorry I missed the couple last comments. While I agree that the problem of dangling active pointers needs a better way of addressing as @samuelmtimbo mentioned, I need to mention the issue is more complicated when it comes to mouse.

There was a reason that we switched to decoupling mouse boundary events and pointerevents boundary events. There was this issue #279 that @graouts previously filed that references the original old issue regarding the moues compat events #35.

I suggest reading the comments on those issues before changing any current behavior but tl;dr is that **there is no guarantee of one to one relation between pointerevents and mouse events** (@garykac @smaug----). Pointerevents are coming each pointer stream and UA will generate compat mouse events based on all of those (whether the device is a mouse or a touch). Mouse events (whether generated by touch or mouse or both interacting with the screen at the same time) needs to be consistent by themselves to satisfy the pages that are only listening to mouse events. The same goes for pointerevents. So you can have a situation that you get a pointerenter event say from a touch (that UA decides to send a compat mouse event for) but there is no matching mouseenter as the mouse pointer was already there on that element (say because of the earlier mouse device moves).

-- 
GitHub Notification of comment by NavidZ
Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/285#issuecomment-725542204 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 17:04:19 UTC