Meeting minutes
Order of pointerover/enter/move and corresponding mouse events is different on browsers https://github.com/w3c/pointerevents/issues/454
Patrick: we discussed this last time, and i realised i've done nothing of my action
Patrick: "patrick to create issue that explains nuance of interleaving in theory vs practice, patrick to recreate animation done by mustaq for inclusion in 11.3"
Patrick: link to minutes from last time https://
Rob: [summarises the issue of browsers that support touch that wait anyway to see if a touch is a gesture before sending mouse events interleaved, as it would break things]
Olli: and this was part of 454?
Mustaq: it was tangentially related - after making the animation, we discussed this behaviour further
<mustaq> https://
<mustaq> The PR is: https://
[short explanation of what the animation is supposed to convey for Olli]
Mustaq: fixed the issue that Rob raised...
Rob: my concern was that it didn't reflect what any browser does, but now that it's delayed it makes sense
Olli: does the animation close the issue or does it still leave the question about order open?
Patrick: I believe we were at the point where we decided that our prose is sufficient, and once we have the animation and explanation it should be clear
pointerout even if the pointer doesn't move? https://github.com/w3c/pointerevents/issues/457
Patrick: i've not had a look at this yet
Mustaq: i looked at this the other day - confirming the behaviour described by Olli
<mustaq> A UI event issue may be relevant:
<mustaq> https://
Mustaq: in this other issue, the DOM is actually modified
Mustaq: in THIS issue in PE, it's a "softer" issue as the DOM doesn't change
Mustaq: that's why i think they're connected
Olli: not sure I see connection. This issue is about pointerout firing even if pointer hasn't moved at all. Compared to DOM changing
Mustaq: other case is also pointer not moving. Firefox seems to remember the state before modification...
Rob: I think when we remove a node, we still remember it as the down node (?)
Mustaq: walking up ancestor tree is an option, but we don't do that
Olli: click event one is a UIEvents issue...
Mustaq: i see it related because it's about how much browsers should remember/try to manage changes
Rob: this is an issue of targeting, we don't do targeting unless pointer is moved
Mustaq: exactly, and i think that's where the difference with firefox's behavior is
Mustaq: when things change in Chrome, it forgets about the DOM tree...
Olli: this issue here is more about display
Olli: did you manage to try this test case in Safari?
Rob: it does NOT send pointerout until you move the cursor
Rob: so Safari is consistent with Firefox here
Olli: any idea why Chrome dispatches the event here?
Olli: I would imagine that there's extra code that actively does this
Rob: it's possible we're doing a hit-test for some reason, and because there's now a different element under the pointer, it triggers the pointerout
Rob: on the original element
Olli: maybe there was some bad compat issue
<flackr> Could be part of https://
Rob: also shout out to the focus area, which could do with some tests
ACTION: add WPT that reflects both Safari and Firefox, investigate reason for Chrome's behaviour
Meta-issue: update WPT to cover Pointer Events Level 3 https://github.com/w3c/pointerevents/issues/445
Patrick: in two week's time would be good to be left just with the closed PRs since last PEv2 that do still need WPT
ACTION: for next meeting, go through all closed PRs and determine where things need a test
Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356
Olli: there was a user counter added?
Mustaq: yes we saw quite a large number of hits on the counter, so need to investigate further why
Mustaq: bit concerned about compat, but need to investigate
Olli: i thought chrome behaviour on mobile and desktop was different, so does the counter take that into account?
Mustaq: this was only an issue for mouse, and mouse on mobile is not that common
Rob: order of events was different I think, but target was same
Rob: we were releaseing implict capture before click in the past, so target same for mouse and touch. just the order of the events that varied
ACTION: investigate further
Patrick: thank you all, that's all I had. Would love to see us make headway with the WPT tests issue for next time. I'll get going with the promised issue to clarify theory/practice of intereleaved pointer/mouse events and looking at adding the animation+explanation to the spec.