14:58:22 <RRSAgent> RRSAgent has joined #pointerevents
14:58:26 <RRSAgent> logging to https://www.w3.org/2023/06/07-pointerevents-irc
14:58:27 <Patrick_H_Lauke> Meeting: PEWG
14:58:31 <Patrick_H_Lauke> Chair: Patrick H. Lauke
14:58:39 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20230607T110000
14:58:48 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
14:58:55 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
14:58:59 <Patrick_H_Lauke> present+
15:00:30 <smaug> present+ smaug
15:01:03 <flackr> flackr has joined #pointerevents
15:01:12 <mustaq> present+ Mustaq
15:01:14 <Patrick_H_Lauke> hmmm...can't seem to start the meeting
15:01:18 <Patrick_H_Lauke> in zoom i mean
15:01:29 <smaug> ah, you're not the host?
15:01:34 <Patrick_H_Lauke> suspect it's because Philippe is still the host
15:01:45 <mustaq> I am seeing "Waiting for host to start the meeting"
15:01:46 <flackr> should we use an alternative for today?
15:01:49 <Patrick_H_Lauke> ok, quick change of plan...firing up a separate zoom. please hold
15:01:54 <Patrick_H_Lauke> snap
15:02:16 <Patrick_H_Lauke> https://us02web.zoom.us/j/9880060302?pwd=Rmk1MUV2b253RE9tVnBJUkZJZ2QzUT09
15:03:49 <Patrick_H_Lauke> TOPIC: Meta-issue: update WPT to cover Pointer Events Level 3 https://github.com/w3c/pointerevents/issues/445
15:03:49 <Patrick_H_Lauke> Go over https://github.com/w3c/pointerevents/issues?q=is%3Aclosed+label%3Aneeds-wpt+
15:04:53 <Patrick_H_Lauke> Patrick: so how are we doing with the WPTs?
15:05:04 <Patrick_H_Lauke> Olli: it's going down. think it was 10-11 last time
15:05:26 <Patrick_H_Lauke> Olli: I closed one, Edgar closed one
15:05:35 <Patrick_H_Lauke> Mustaq: I closed one, and have one waiting for review
15:05:45 <Patrick_H_Lauke> Olli: added a comment to the one about secure context
15:06:10 <Patrick_H_Lauke> Olli: that's something we probably need to change. would be risky right now to hide the whole method, instead we could always expose the same event as the real event
15:06:14 <mustaq> https://github.com/w3c/pointerevents/pull/318
15:06:53 <Patrick_H_Lauke> Mustaq: agree it's risky, don't think we have a counter. not sure how many sites rely on this. probably just returning empty list would be ok
15:07:12 <Patrick_H_Lauke> Olli: not thinking empty list, it should always have one, so just send a copy of the same parent event
15:07:32 <Patrick_H_Lauke> Olli: so we'd need to change the spec a tiny bit
15:07:45 <Patrick_H_Lauke> Olli: worried some libraries might already rely on this, but don't have any data.
15:07:50 <Patrick_H_Lauke> Mustaq: think we can go for it
15:08:14 <Patrick_H_Lauke> Olli: issue filed for this here https://github.com/w3c/pointerevents/issues/472
15:08:25 <Patrick_H_Lauke> Rob: wouldn't want to change things until we have data
15:08:41 <Patrick_H_Lauke> Rob: APIs have been around for a long time, so best to wait for data
15:08:59 <Patrick_H_Lauke> Olli: what i'm suggesting would not break API though, it just returns a single item list
15:09:27 <Patrick_H_Lauke> Mustaq: if we can count how many times getCoalescedEvent gets called in a non-secure context, we can switch it over
15:10:03 <Patrick_H_Lauke> Rob: if we had the data to suggest that this isn't being used from non-secure context, we should remove the method. would be less surprising
15:12:14 <Patrick_H_Lauke> Olli: but if the API doesn't break, just that it only returns a single item...
15:12:25 <Patrick_H_Lauke> [discussion on whether we want to wait for data or not]
15:13:02 <Patrick_H_Lauke> Patrick: i'd suggest going for the "simpler" approach that Olli suggested - keep method/API, but clarify that the list only contains a single CLONE of the parent event
15:13:42 <Patrick_H_Lauke> Patrick: but also gather data, then we can in future think about removing the method altogether in non-secure context if data shows that nobody's using it in those cases
15:14:38 <Patrick_H_Lauke> ACTION: Patrick to look at #472 and propose PR to clarify what happens in non-secure contexts (only returns a list with single item, CLONE of parent)
15:15:58 <Patrick_H_Lauke> Olli: was also trying to look at https://github.com/w3c/pointerevents/pull/390 ...
15:16:08 <Patrick_H_Lauke> Mustaq: I landed a change, by end of today you should be able to test it
15:16:25 <mustaq> It is an automated test now.
15:16:28 <Patrick_H_Lauke> Patrick: so let's carry on with this. will send reminder a week before next meeting
15:16:35 <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:19:15 <Patrick_H_Lauke> Patrick: since last meeting, I spent some time visually highlighting the outlier results in https://github.com/w3c/pointerevents/issues/356#issuecomment-1542921101 ... now clearer to see where the differences in click are, but there's also a very weird outlier in Safari/iOS for the second scenario, which does look more like a bug at their end than  something Safari team explicitly did, since Safari/macOS doesn't have this[CUT]
15:19:15 <Patrick_H_Lauke> either
15:20:34 <Patrick_H_Lauke> [looking at what we decided last time]
15:21:26 <Patrick_H_Lauke> Patrick: minutes from last time https://www.w3.org/2023/05/24-pointerevents-minutes.html
15:21:41 <Patrick_H_Lauke> [more discussion on what we went over previously]
15:23:10 <Patrick_H_Lauke> Mustaq: ... most recent discussion was about async click...
15:23:53 <Patrick_H_Lauke> Patrick: minutes from two meetings ago has more of our thinking at the time https://www.w3.org/2023/05/10-pointerevents-minutes.html
15:24:37 <Patrick_H_Lauke> Rob: ...click event is not meant to be separately targeted, so should not be different from the up event... do the computation of what click target should be at the point where we do the up event...
15:25:22 <Patrick_H_Lauke> Mustaq: challenge is that lostpointercapture has been fired, but then forcing click to go to what was captured before (and click going to blue)
15:25:59 <Patrick_H_Lauke> Olli: ...what happens to the mouseup - i know it's legacy, but still used...
15:26:13 <Patrick_H_Lauke> Olli: what is the target of that if pointerup explicitly releases
15:26:37 <Patrick_H_Lauke> Mustaq: with mouse it's easier, because everything is synchronous
15:26:46 <Patrick_H_Lauke> Olli: just wondering what the behaviour here should be though
15:29:43 <Patrick_H_Lauke> Olli: may also need to add mousedown/mouseup, as some of the behaviour we see may be related to these legacy events
15:30:00 <Patrick_H_Lauke> Rob: also don't want to forget what author/developer expectation would be when using pointer capture
15:33:15 <Patrick_H_Lauke> Patrick: i guess as developer, i wouldn't care about where the mouseup happens if i'm capturing... but i think what we're getting at is that the need to create legacy mouse events MAY be the root cause of this weirdness, since we didn't spec it so precisely ourselves.
15:34:28 <Patrick_H_Lauke> ACTION: Extend the test codepen to also include mousedown/mouseup, rerun results
15:36:50 <Patrick_H_Lauke> ACTION: before next meeting, will send email reminding everybody to COME PREPARED with their own take of what the best/most reasonable way forward here is
15:37:07 <Patrick_H_Lauke> Rob: related, do we know of any major sites using pointer capture?
15:37:49 <Patrick_H_Lauke> Patrick: I often feel no real-world developer out there is making heavy use of pointerevents, though now pleased to see sessions from latest Apple event consistently now using pointerevents
15:38:01 <Patrick_H_Lauke> Mustaq: I have vague memories of some side-scrolling game using it...
15:38:31 <Patrick_H_Lauke> Rob: more interesting then as well - how many sites are using capture AND are then hot-swapping the element that has capture, i guess not many
15:38:41 <Patrick_H_Lauke> Rob: let's do a detailed session next time about this
15:41:03 <mustaq> https://github.com/w3c/pointerevents/issues/303
15:41:31 <Patrick_H_Lauke> TOPIC: spec doesn't match WPTs #303
15:42:06 <Patrick_H_Lauke> Mustaq: railing behaviour in WPT - once scroll starts, Chrome tries to latch onto that direction...
15:43:48 <Patrick_H_Lauke> Mustaq: [explains current behaviour in Chrome, which passes the WPT, but all other browsers fail?]
15:46:01 <Patrick_H_Lauke> [discussion on what current behaviour in Chrome is...that the browser can take over in the course of an ongoing gesture]
15:47:32 <Patrick_H_Lauke> Mustaq: the test was done a long time ago, legacy behaviour
15:48:09 <Patrick_H_Lauke> Patrick: i'd say most sensible would be to change the test and Chrome's legacy behaviour, and make sure our spec is clear about ONGOING gestures
15:49:15 <Patrick_H_Lauke> Rob: [mentions the "slop" and the point at which a developer could safely assume whether the browser is scrolling or if they now have control over that gesture]
15:50:14 <Patrick_H_Lauke> Mustaq: at some point (?) we had the philosophy that browser could take over at any point even for ongoing gestures
15:50:28 <Patrick_H_Lauke> Mustaq: definition of "slop" is not in the spec
15:50:55 <Patrick_H_Lauke> Rob: but it's developer-observable. move fires at the point where you exceed the slop region
15:52:18 <Patrick_H_Lauke> Olli: do you happen to have a test case for all this (not necessarily WPT, just anywhere)
15:52:31 <Patrick_H_Lauke> Mustaq: we have quite a few tests in WPT
15:52:54 <Patrick_H_Lauke> Rob: you can look at the cancelable flag on the move event, and you can tell from that whether it started to scroll
15:53:21 <Patrick_H_Lauke> Rob: once we start a scroll it's no longer cancelable
15:53:39 <Patrick_H_Lauke> Olli: spec says pointermove is always cancelable
15:54:39 <mustaq> https://w3c.github.io/pointerevents/#attributes-and-default-actions
15:54:57 <Patrick_H_Lauke> Patrick: but no pointermoves are sent when scrolling starts
15:55:06 <Patrick_H_Lauke> Rob: but on that last event before it scrolls...
15:56:03 <Patrick_H_Lauke> Rob: how can dev tell in their pointer handler that browser took over scrolling
15:58:33 <Patrick_H_Lauke> [more discussion]
16:01:17 <Patrick_H_Lauke> Rob: going back to initial issue, we should make sure that only initial direction is used, and browser does not decide during an ongoing gesture to jump back in and take over scrolling
16:01:43 <Patrick_H_Lauke> Patrick: agree, change WPT accordingly, make sure spec is explicit about it, and then change chrome behaviour
16:02:03 <Patrick_H_Lauke> Rob: do we know any sites that rely on this particular behaviour, if it only happens in Chrome
16:07:41 <Patrick_H_Lauke> ACTION: test #303 not in webdriver (which has potential bugs), but in real browser
16:08:31 <Patrick_H_Lauke> Rob: one more point against current behaviour is the asymmetry of the behaviour...
16:14:46 <Patrick_H_Lauke> RRSAgent, make logs world-visible
16:15:20 <Patrick_H_Lauke> RRSAgent, generate minutes
16:15:21 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/07-pointerevents-minutes.html Patrick_H_Lauke
16:21:00 <Patrick_H_Lauke> present+ flackr
16:21:10 <Patrick_H_Lauke> RRSAgent, generate minutes
16:21:11 <RRSAgent> I have made the request to generate https://www.w3.org/2023/06/07-pointerevents-minutes.html Patrick_H_Lauke
16:21:44 <Patrick_H_Lauke> RRSAgent, bye
16:21:44 <RRSAgent> I see 4 open action items saved in https://www.w3.org/2023/06/07-pointerevents-actions.rdf :
16:21:44 <RRSAgent> ACTION: Patrick to look at #472 and propose PR to clarify what happens in non-secure contexts (only returns a list with single item, CLONE of parent) [1]
16:21:44 <RRSAgent>   recorded in https://www.w3.org/2023/06/07-pointerevents-irc#T15-14-38
16:21:44 <RRSAgent> ACTION: Extend the test codepen to also include mousedown/mouseup, rerun results [2]
16:21:44 <RRSAgent>   recorded in https://www.w3.org/2023/06/07-pointerevents-irc#T15-34-28
16:21:44 <RRSAgent> ACTION: before next meeting, will send email reminding everybody to COME PREPARED with their own take of what the best/most reasonable way forward here is [3]
16:21:44 <RRSAgent>   recorded in https://www.w3.org/2023/06/07-pointerevents-irc#T15-36-50
16:21:44 <RRSAgent> ACTION: test #303 not in webdriver (which has potential bugs), but in real browser [4]
16:21:44 <RRSAgent>   recorded in https://www.w3.org/2023/06/07-pointerevents-irc#T16-07-41