pointerenter vs. pointerleave dispatch sequence

[graouts]

I'm working on the WebKit implementation of Pointer Events and found this discrepancy in the tree order in which pointerenter and pointerleave events are dispatched between WebKit and Chrome/Firefox. See WebKit bug #198036.

I couldn't find where the Pointer Events spec normatively defines the tree order for dispatch of those events. Could someone point me to it? If it doesn't exist, should we be worried about the potential divergence in implementation?

[patrickhlauke]

i don't believe the exact order is normatively defined beyond what it says in https://w3c.github.io/pointerevents/#compatibility-mapping-with-mouse-events (which itself is an optional feature). i think divergence in this case is reasonably safe as i would hope no code in the wild would rely/do anything with the exact order of pointer event and compat events

[NavidZ]

I'm not sure if I fully understood the title of this bug compared to what the WebKit bug #198036 talks about. The Webkit bug talks about this other spec issue. I assume the discussion there was acceptable.
But if you are talking about sending pointerenter and pointerleave when we have nested elements I believe we wanted to follow the same logic as mouse events that are described in this example in UI events.

[graouts]

@NavidZ I see how this could be confusing. But this spec issue is indeed relevant, if I filter out the mouse events, the sequences are:

In STP 82:

Received pointerenter on <div id="bottom">
Received pointerenter on <div id="middle">
Received pointerenter on <div id="top">

In Chrome and Firefox:

Received pointerenter on <div id="top">
Received pointerenter on <div id="middle">
Received pointerenter on <div id="bottom">

Notice how STP goes from bottom to top while Chrome and Firefox go into the other direction.

But @patrickhlauke seems to say that this shouldn't matter.

[NavidZ]

@patrickhlauke was referring to the compatibility mouse events part of it and it should not matter.
@garykac FYI

In terms of the ordering of the enter and leave events when there is a nested set of nodes I believe the UI events spec link I gave is normative. It seems Webkit doesn't follow that for mouse events either. I think whatever we do we should do the same for mouseevents and pointerevents.
Having said that, it does seem that there is no real issue in the wild as per Webkit issue. But I'm still inclined to follow what UI event specifies.

[graouts]

Thanks for the link @NavidZ, this makes me think that we should fix this in WebKit for both mouse events and pointer events.

[NavidZ]

@graouts if you are planning to fix Webkit here is there anything else remains for this issue? Can we close it?

[graouts]

Yes.