14:58:04 <RRSAgent> RRSAgent has joined #pointerevents
14:58:08 <RRSAgent> logging to https://www.w3.org/2023/05/10-pointerevents-irc
14:58:23 <Patrick_H_Lauke> Meeting: PEWG
14:58:29 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:58:37 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/81ad3e7c-6dde-48ec-8693-09a9adea9f69/20230510T110000
14:58:56 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:58:56 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
14:58:56 <Patrick_H_Lauke> present+
15:02:28 <flackr> flackr has joined #pointerevents
15:02:38 <Patrick_H_Lauke> present+ smaug
15:02:48 <Patrick_H_Lauke> present+ mustaq
15:02:52 <Patrick_H_Lauke> present+ flackr
15:03:32 <Patrick_H_Lauke> TOPIC: Meta-issue: update WPT to cover Pointer Events Level 3 https://github.com/w3c/pointerevents/issues/445
15:03:32 <Patrick_H_Lauke> Go over https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+
15:04:01 <Patrick_H_Lauke> Olli: wonder how we can get through all these tests
15:04:47 <Patrick_H_Lauke> Mustaq: was hoping to do more, but not had time
15:05:03 <Patrick_H_Lauke> Patrick: I'll see if i can get env set up for testing at my end, but should we rope in extra help?
15:05:12 <Patrick_H_Lauke> Olli: I'll see if I can get Edgar (?) to help
15:05:16 <Patrick_H_Lauke> Mustaq: same here
15:05:43 <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:05:55 <Patrick_H_Lauke> Patrick: did some testing with the latest codepen
15:12:06 <Patrick_H_Lauke> https://github.com/w3c/pointerevents/issues/356#issuecomment-1542350997
15:12:49 <Patrick_H_Lauke> Patrick: only tested with `touch-action` and explicit release. Can rerun/document tests also with the explicit release disabled
15:13:13 <Patrick_H_Lauke> [discussion on whether we should also test all other iterations]
15:14:43 <Patrick_H_Lauke> Mustaq: originally, we didn't have implicit capture/implicit release, but we convinced Microsoft at the time that we'd do implicit capture for touch, but releasing would be same for all pointer types (?)
15:15:05 <Patrick_H_Lauke> Rob: if devs use pointer capture, they can rely on implicit release, or do it themselves explicitly
15:16:05 <Patrick_H_Lauke> Mustaq: if implicit release is different from explicit release, then that's a problem/bug
15:17:35 <Patrick_H_Lauke> ACTION: do more testing with explicit capture off and document results
15:18:01 <flackr> https://w3c.github.io/pointerevents/#implicit-release-of-pointer-capture
15:18:27 <flackr> "If the user agent supports firing the click or auxclick event, and if in an implicit release scenario both that (click or auxclick) event and a lostpointercapture event are fired, the click or auxclick event SHOULD be fired before lostpointercapture."
15:19:01 <Patrick_H_Lauke> Rob: this is what led me to believe that explicit release is different from implicit release. if you think they should be the same, then we should remove that
15:19:19 <Patrick_H_Lauke> Olli: didn't i file a spec issue that said the opposite of this? the order was unclear
15:19:34 <smaug> https://github.com/w3c/pointerevents/issues/357
15:20:23 <Patrick_H_Lauke> Mustaq: calling release doesn't immediately release, so there may be some leeway
15:20:32 <Patrick_H_Lauke> Rob: but we'd still expect the click to be captured
15:21:03 <Patrick_H_Lauke> Rob: but that does affect what i'd expect the outcome to be. until lostpointercapture, i'd expect the click to be captured
15:21:15 <Patrick_H_Lauke> Mustaq: it's because of the async nature
15:21:42 <Patrick_H_Lauke> Rob: we should either consistently delay pointer capture before, or after. not having click dispatched sync or async and get different results
15:22:01 <Patrick_H_Lauke> Rob: behaviour i was pushing for is changing touch behaviour so we don't use the pointer capture until after click is dispatched
15:23:35 <Patrick_H_Lauke> Mustaq: for touch, we also have pointerleave and pointerout. which then also trigger the capture release. if we make click sync, these will also need to be addressed
15:24:24 <Patrick_H_Lauke> Rob: naive thing would be to delay out and leave if you have delayed clicks, which doesn't seem crazy but is a pretty big change, perhaps argument in favour of losing pointer capture before the click...
15:24:59 <Patrick_H_Lauke> Mustaq: looking for section about pending pointer capture
15:25:01 <Patrick_H_Lauke> Patrick: https://w3c.github.io/pointerevents/#process-pending-pointer-capture
15:25:35 <Patrick_H_Lauke> Mustaq: "The user agent MUST run..." so this includes out and leave
15:25:37 <Patrick_H_Lauke> Rob: and click
15:25:47 <Patrick_H_Lauke> Mustaq: but this was done before click
15:25:54 <Patrick_H_Lauke> Rob: so spec is contradicting itself
15:26:30 <Patrick_H_Lauke> Patrick: Rob do you want to file an issue on this?
15:26:39 <Patrick_H_Lauke> Olli: my issue is about this https://github.com/w3c/pointerevents/issues/357
15:27:36 <Patrick_H_Lauke> Rob: one question is: simplest change would be release pointer capture after pointer up. then click goes to common ancestor of common ancestor and the down event
15:28:02 <Patrick_H_Lauke> Rob: we did some compat evaluation for this at some point?
15:28:05 <Patrick_H_Lauke> Mustaq: not for this one
15:28:34 <Patrick_H_Lauke> Rob: less worried about order than the target
15:28:45 <Patrick_H_Lauke> Mustaq: compat could also be deciding factor
15:29:02 <Patrick_H_Lauke> Rob: what would happen if we lost pointer capture before click and fired click at the ancestor
15:29:13 <Patrick_H_Lauke> Rob: how many pages would this affect, or something to that effect
15:29:45 <Patrick_H_Lauke> Mustaq: could you add this as a comment to the issue (https://github.com/w3c/pointerevents/issues/356)
15:31:34 <Patrick_H_Lauke> Olli: maybe safari on desktop is the simplest
15:33:27 <Patrick_H_Lauke> Olli: for cases 3 and 4
15:33:41 <Patrick_H_Lauke> Patrick: it's doing what Rob is suggesting, firing click to ancestor after capture lost
15:33:54 <Patrick_H_Lauke> Rob: but then row 2 is weird, firing click to green
15:34:23 <Patrick_H_Lauke> Olli: ... then there's also the weirdness for devs who do capture and then assume that means they'll also get the click
15:34:41 <Patrick_H_Lauke> Rob: that would assume changing how capture works to wait for click as well, the other way of solving this
15:36:03 <Patrick_H_Lauke> Mustaq: ... we could say even though point is lost, click still goes to the element where the pointerup happened
15:36:25 <Patrick_H_Lauke> Rob: ergonomically, this is more useful for devs, but would rather do something that's more generally useful even though harder to spec
15:36:34 <Patrick_H_Lauke> Mustaq: we should definitely check on compat
15:36:45 <Patrick_H_Lauke> Rob: we could see how often target gets changed
15:36:55 <Patrick_H_Lauke> Mustaq: I think we DID test that aspect, we added a counter....
15:37:29 <Patrick_H_Lauke> Mustaq: had planned to add a test in canary, but we didn't get to that point
15:37:56 <Patrick_H_Lauke> Mustaq: the bug mentions a counter, but we didn't post the result back
15:38:42 <Patrick_H_Lauke> [checking if counter is still there or expired]
15:40:21 <flackr> https://chromestatus.com/metrics/feature/timeline/popularity/3942
15:41:23 <Patrick_H_Lauke> Rob: even if target changes, doesn't tell us if page breaks
15:42:05 <Patrick_H_Lauke> Mustaq: what's next step then? I think we should report this upper bound in the issue
15:42:11 <Patrick_H_Lauke> Rob: I left it in IRC/notes
15:43:11 <Patrick_H_Lauke> Rob: I do notice - I don't think this counter cares if there's a click handler or not. so would be possible to try to get a better estimate / lower upper bound of when there ARE click handlers for the old/new target
15:44:00 <Patrick_H_Lauke> Olli: and you'd have to check if there's elements like anchors
15:44:05 <Patrick_H_Lauke> Mustaq: Rob for now I'll reopen the issue for this counter in case we need to fine-tune this one, WDYT
15:44:40 <Patrick_H_Lauke> Rob: risk is unknown, we have an upper bound, we might try to launch something with caveat that if we see significant breakage we pull back
15:45:05 <Patrick_H_Lauke> Mustaq: let's continue this outside of the meeting
15:47:16 <Patrick_H_Lauke> ACTION: Rob/Mustaq to investigate further about counter/test to get more data to make decision
15:48:50 <Patrick_H_Lauke> TOPIC: TPAC
15:49:00 <Patrick_H_Lauke> Patrick: so the dates/times that were available are
15:49:08 <Patrick_H_Lauke>  > Monday 11 September: 09:30 - 11:00
15:49:08 <Patrick_H_Lauke>   > Monday 11 September: 11:30 - 13:00
15:49:08 <Patrick_H_Lauke>   > Monday 11 September: 17:00 - 18:30
15:49:08 <Patrick_H_Lauke>   > Tuesday 12 September: 09:30 - 11:00
15:49:10 <Patrick_H_Lauke>   > Tuesday 12 September: 11:30 - 13:00
15:49:12 <Patrick_H_Lauke>   > Tuesday 12 September: 17:00 - 18:30
15:49:14 <Patrick_H_Lauke>   > Thursday 14 September: 09:30 - 11:00
15:49:16 <Patrick_H_Lauke>   > Thursday 14 September: 11:30 - 13:00
15:49:18 <Patrick_H_Lauke>   > Thursday 14 September: 17:00 - 18:30
15:49:20 <Patrick_H_Lauke>   > Friday 15 September: 09:30 - 11:00
15:49:22 <Patrick_H_Lauke>   > Friday 15 September: 11:30 - 13:00
15:49:24 <Patrick_H_Lauke>   > Friday 15 September: 17:00 - 18:30
15:52:08 <Patrick_H_Lauke> [discussion on which date/time would preliminarily work]
15:52:44 <Patrick_H_Lauke> Patrick: so I'll put us down for thursday 14 September 17:00-18:30, we can always change it (within reason) on an ad-hoc basis as it's just the four of us
15:52:57 <Patrick_H_Lauke> ACTION: complete TPAC session form
15:55:09 <Patrick_H_Lauke> RRSAgent, set logs world-visible
15:55:16 <Patrick_H_Lauke> RRSAgent, generate minutes
15:55:17 <RRSAgent> I have made the request to generate https://www.w3.org/2023/05/10-pointerevents-minutes.html Patrick_H_Lauke
15:55:46 <Patrick_H_Lauke> RRSAgent, bye
15:55:46 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2023/05/10-pointerevents-actions.rdf :
15:55:46 <RRSAgent> ACTION: do more testing with explicit capture off and document results [1]
15:55:46 <RRSAgent>   recorded in https://www.w3.org/2023/05/10-pointerevents-irc#T15-17-35
15:55:46 <RRSAgent> ACTION: Rob/Mustaq to investigate further about counter/test to get more data to make decision [2]
15:55:46 <RRSAgent>   recorded in https://www.w3.org/2023/05/10-pointerevents-irc#T15-47-16
15:55:46 <RRSAgent> ACTION: complete TPAC session form [3]
15:55:46 <RRSAgent>   recorded in https://www.w3.org/2023/05/10-pointerevents-irc#T15-52-57