- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 12 Oct 2022 16:42:36 +0100
- To: public-pointer-events@w3.org
Dear all, the minutes from today's meeting are at https://www.w3.org/2022/10/12-pointerevents-minutes.html and copied below: PEWG 12 October 2022 Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20221012T110000 Attendees flackr, mustaq, Patrick_H_Lauke, smaug Chair: Patrick H. Lauke Scribe: Patrick H. Lauke, Patrick_H_Lauke * Order of pointerover/enter/move and corresponding mouse events is different on browsers https://github.com/w3c/pointerevents/issues/454 * pointerout even if the pointer doesn't move? https://github.com/w3c/pointerevents/issues/457 * Meta-issue: update WPT to cover Pointer Events Level 3 https://github.com/w3c/pointerevents/issues/445 * Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356 # 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://www.w3.org/2022/09/28-pointerevents-minutes.html#t01 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://mustaqahmed.github.io/web/pe-legacy-pointer-animation/legacy-pointer-animation.html <mustaq> The PR is: https://github.com/w3c/pointerevents/pull/458 [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://github.com/w3c/uievents/issues/141 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://github.com/web-platform-tests/interop/issues/202 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. -- Patrick H. Lauke https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 12 October 2022 15:42:51 UTC