14:54:23 <RRSAgent> RRSAgent has joined #pointerevents
14:54:23 <RRSAgent> logging to https://www.w3.org/2022/10/12-pointerevents-irc
14:54:39 <Patrick_H_Lauke> Meeting: PEWG
14:54:45 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:54:53 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/0d3af70c-0054-43dc-9c15-c60c5b9c3f3c/20221012T110000
14:55:09 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:55:16 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
14:55:23 <Patrick_H_Lauke> present+ Patrick_H_Lauke
14:57:38 <smaug> present+ smaug
15:01:30 <flackr> flackr has joined #pointerevents
15:03:04 <Patrick_H_Lauke> present+ flackr
15:04:17 <Patrick_H_Lauke> present+ mustaq
15:04:44 <Patrick_H_Lauke> TOPIC: Order of pointerover/enter/move and corresponding mouse events is different on browsers https://github.com/w3c/pointerevents/issues/454
15:05:20 <Patrick_H_Lauke> Patrick: we discussed this last time, and i realised i've done nothing of my action
15:05:28 <Patrick_H_Lauke> 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"
15:06:33 <Patrick_H_Lauke> Patrick: link to minutes from last time https://www.w3.org/2022/09/28-pointerevents-minutes.html#t01
15:07:14 <Patrick_H_Lauke> 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]
15:07:42 <Patrick_H_Lauke> Olli: and this was part of 454?
15:07:57 <Patrick_H_Lauke> Mustaq: it was tangentially related - after making the animation, we discussed this behaviour further
15:07:58 <mustaq> https://mustaqahmed.github.io/web/pe-legacy-pointer-animation/legacy-pointer-animation.html
15:08:39 <mustaq> The PR is: https://github.com/w3c/pointerevents/pull/458
15:10:25 <Patrick_H_Lauke> [short explanation of what the animation is supposed to convey for Olli]
15:10:43 <Patrick_H_Lauke> Mustaq: fixed the issue that Rob raised...
15:11:02 <Patrick_H_Lauke> Rob: my concern was that it didn't reflect what any browser does, but now that it's delayed it makes sense
15:13:33 <Patrick_H_Lauke> Olli: does the animation close the issue or does it still leave the question about order open?
15:13:59 <Patrick_H_Lauke> 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
15:14:17 <Patrick_H_Lauke> TOPIC: pointerout even if the pointer doesn't move? https://github.com/w3c/pointerevents/issues/457
15:14:51 <Patrick_H_Lauke> Patrick: i've not had a look at this yet
15:15:23 <Patrick_H_Lauke> Mustaq: i looked at this the other day - confirming the behaviour described by Olli
15:16:37 <mustaq> A UI event issue may be relevant:
15:16:37 <mustaq> https://github.com/w3c/uievents/issues/141
15:17:21 <Patrick_H_Lauke> Mustaq: in this other issue, the DOM is actually modified
15:17:40 <Patrick_H_Lauke> Mustaq: in THIS issue in PE, it's a "softer" issue as the DOM doesn't change
15:17:49 <Patrick_H_Lauke> Mustaq: that's why i think they're connected
15:18:24 <Patrick_H_Lauke> Olli: not sure I see connection. This issue is about pointerout firing even if pointer hasn't moved at all. Compared to DOM changing
15:18:52 <Patrick_H_Lauke> Mustaq: other case is also pointer not moving. Firefox seems to remember the state before modification...
15:20:21 <Patrick_H_Lauke> Rob: I think when we remove a node, we still remember it as the down node (?)
15:20:52 <Patrick_H_Lauke> Mustaq: walking up ancestor tree is an option, but we don't do that
15:21:25 <Patrick_H_Lauke> Olli: click event one is a UIEvents issue...
15:21:48 <Patrick_H_Lauke> Mustaq: i see it related because it's about how much browsers should remember/try to manage changes
15:22:07 <Patrick_H_Lauke> Rob: this is an issue of targeting, we don't do targeting unless pointer is moved
15:22:27 <Patrick_H_Lauke> Mustaq: exactly, and i think that's where the difference with firefox's behavior is
15:22:49 <Patrick_H_Lauke> Mustaq: when things change in Chrome, it forgets about the DOM tree...
15:22:56 <Patrick_H_Lauke> Olli: this issue here is more about display
15:23:20 <Patrick_H_Lauke> Olli: did you manage to try this test case in Safari?
15:23:29 <Patrick_H_Lauke> Rob: it does NOT send pointerout until you move the cursor
15:24:03 <Patrick_H_Lauke> Rob: so Safari is consistent with Firefox here
15:24:18 <Patrick_H_Lauke> Olli: any idea why Chrome dispatches the event here?
15:24:35 <Patrick_H_Lauke> Olli: I would imagine that there's extra code that actively does this
15:25:04 <Patrick_H_Lauke> 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
15:25:11 <Patrick_H_Lauke> Rob: on the original element
15:26:09 <Patrick_H_Lauke> Olli: maybe there was some bad compat issue
15:26:32 <flackr> Could be part of https://github.com/web-platform-tests/interop/issues/202
15:26:39 <Patrick_H_Lauke> Rob: also shout out to the focus area, which could do with some tests
15:29:40 <Patrick_H_Lauke> Action: add WPT that reflects both Safari and Firefox, investigate reason for Chrome's behaviour
15:29:55 <Patrick_H_Lauke> TOPIC: Meta-issue: update WPT to cover Pointer Events Level 3 https://github.com/w3c/pointerevents/issues/445
15:32:28 <Patrick_H_Lauke> 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
15:32:44 <Patrick_H_Lauke> ACTION: for next meeting, go through all closed PRs and determine where things need a test
15:33:38 <Patrick_H_Lauke> TOPIC: Heartbeat: Clarify what the target of the click event should be after capturing pointer events https://github.com/w3c/pointerevents/issues/356
15:34:25 <Patrick_H_Lauke> Olli: there was a user counter added?
15:34:48 <Patrick_H_Lauke> Mustaq: yes we saw quite a large number of hits on the counter, so need to investigate further why
15:35:05 <Patrick_H_Lauke> Mustaq: bit concerned about compat, but need to investigate
15:35:32 <Patrick_H_Lauke> Olli: i thought chrome behaviour on mobile and desktop was different, so does the counter take that into account?
15:35:45 <Patrick_H_Lauke> Mustaq: this was only an issue for mouse, and mouse on mobile is not that common
15:35:54 <Patrick_H_Lauke> Rob: order of events was different I think, but target was same
15:36:14 <Patrick_H_Lauke> 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
15:36:26 <Patrick_H_Lauke> ACTION: investigate further
15:38:49 <Patrick_H_Lauke> 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.
15:39:01 <Patrick_H_Lauke> rrsagent, make logs world-visible
15:39:10 <Patrick_H_Lauke> rrsagent, generate minutes
15:39:10 <RRSAgent> I have made the request to generate https://www.w3.org/2022/10/12-pointerevents-minutes.html Patrick_H_Lauke
15:39:16 <Patrick_H_Lauke> rrsagent, make logs world-visible
15:39:33 <Patrick_H_Lauke> rrsagent, bye
15:39:33 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2022/10/12-pointerevents-actions.rdf :
15:39:33 <RRSAgent> ACTION: add WPT that reflects both Safari and Firefox, investigate reason for Chrome's behaviour [1]
15:39:33 <RRSAgent>   recorded in https://www.w3.org/2022/10/12-pointerevents-irc#T15-29-40
15:39:33 <RRSAgent> ACTION: for next meeting, go through all closed PRs and determine where things need a test [2]
15:39:33 <RRSAgent>   recorded in https://www.w3.org/2022/10/12-pointerevents-irc#T15-32-44
15:39:33 <RRSAgent> ACTION: investigate further [3]
15:39:33 <RRSAgent>   recorded in https://www.w3.org/2022/10/12-pointerevents-irc#T15-36-26