15:47:31 <RRSAgent> RRSAgent has joined #pointerevents
15:47:35 <RRSAgent> logging to https://www.w3.org/2025/01/29-pointerevents-irc
15:54:16 <Patrick_H_Lauke> Meeting: PEWG
15:54:31 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/66591f6b-6694-4f90-b23d-bf8f1b9dda8a/20250129T110000/
15:54:36 <Patrick_H_Lauke> Chair: Patrick H. Lauke
15:54:39 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
15:55:03 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
16:04:27 <Patrick_H_Lauke> present+ flackr
16:04:31 <Patrick_H_Lauke> present+
16:04:35 <Patrick_H_Lauke> present+ mustaq
16:05:22 <Patrick_H_Lauke> regrets+ smaug
16:05:58 <Patrick_H_Lauke> TOPIC: Action items from previous meeting
16:06:01 <Patrick_H_Lauke> Rob to follow up on https://github.com/w3c/pointerevents/issues/516
16:07:21 <Patrick_H_Lauke> Rob: CSS WG has a bot that files minutes to issues, can we have that?
16:07:25 <Patrick_H_Lauke> Patrick: I'll ask PLH
16:07:32 <Patrick_H_Lauke> context of the action was https://www.w3.org/2024/12/18-pointerevents-minutes.html#ee66
16:08:23 <Patrick_H_Lauke> mustaq: didn't we say we'd explore other avenues other than PE? i might be misremembering
16:08:39 <Patrick_H_Lauke> Patrick: we already decided that we'd defer this to future, not cramming into v3, so no major rush
16:09:04 <Patrick_H_Lauke> https://www.w3.org/2024/12/04-pointerevents-minutes.html#d477
16:16:34 <Patrick_H_Lauke> [Group discusses again the intricacies of new handwriting touch-action, and where this new value would need to be assumed to be included, and other cases where authors will have to explicitly add it, e.g. when they explicitly defined a touch-action for pan-x but they now ALSO want handwriting, but in other cases it has to be assumed like for touch-action: none]
16:18:49 <Patrick_H_Lauke> Patrick: can we add something to https://github.com/w3c/pointerevents/issues/516
16:19:55 <Patrick_H_Lauke> ACTION: Rob to add a small reminder (to ourselves, mainly) what our current thinking/challenges are for https://github.com/w3c/pointerevents/issues/516
16:20:16 <Patrick_H_Lauke> Patrick: other action we had was - Group to review https://github.com/w3c/pointerevents/pull/532 for this meeting
16:21:27 <Patrick_H_Lauke> mustaq: on the outstanding comment from Rob - think we want to call out primary pointer mainly because no implementation does hover for anything other than primary
16:21:44 <Patrick_H_Lauke> Rob: seems strange that you get boundary updates for one finger rather than ohters
16:22:45 <Patrick_H_Lauke> mustaq: wanted to maintain what UI Events spec does ... at least my interpretation. this calculation is expensive, so i think that's the rationale for calling out primary, since that's also only one that hovers. i can open a new issue separately, or we can work still on this PR
16:24:02 <Patrick_H_Lauke> Rob: with this PR we match mouseover/mouseout behaviour for the primary pointer event
16:24:41 <Patrick_H_Lauke> Rob: UI Events talks about mouse, and then introduces primary pointer...which is confusing
16:24:56 <Patrick_H_Lauke> Rob: maybe we limit this to cases where you only have one active pointer, which is the primary pointer of the current type
16:25:21 <Patrick_H_Lauke> Rob: primary touch is only primary while there's only one touch?
16:26:09 <Patrick_H_Lauke> mustaq: you mouse hovering element A, you tap element B. does the mouse jump? on some implementations it does, on others the mouse pointer disappears
16:26:47 <Patrick_H_Lauke> Rob: i think the visible movement of mouse is a legacy from older touch devices...
16:28:49 <Patrick_H_Lauke> Patrick: that's more a visual UI thing left up to UAs, not something that concerns us anyway. the "disappeared" mouse pointer moves to where your touch was, and when you wiggle the mouse again the UA decides to either start from that touch position, or from the previously known mouse position (?)
16:29:28 <Patrick_H_Lauke> Rob: we might only be able to do this for devices that DON'T have implicit capture
16:31:26 <Patrick_H_Lauke> Rob: hover effect is only caused by the legacy mouse pointer. because touch has implicit capture, maybe we don't need to worry as you can't change the target underneath it... (?)
16:31:46 <Patrick_H_Lauke> Rob: ... unless you removed capture, which I think you can do / release
16:31:53 <Patrick_H_Lauke> Rob: which is going to be an edge case
16:32:16 <Patrick_H_Lauke> mustaq: i think implicit capture is the only one that makes the distinction....
16:33:31 <flackr> https://w3c.github.io/pointerevents/#implicit-pointer-capture
16:33:34 <Patrick_H_Lauke> Rob: you raised performance, but if we assume that a captured pointer doesn't change its target, we don't need to worry about it...so performance hit only for edge case?
16:34:06 <Patrick_H_Lauke> Rob: we can remove that whole active pointer requirement, and have no perf hit, because most times pointers will be captured
16:34:18 <Patrick_H_Lauke> mustaq: so I should remove the primary condition bit
16:34:30 <Patrick_H_Lauke> mustaq: do we need to discuss further, or we settled
16:34:39 <Patrick_H_Lauke> Rob: to make everything nice and consistent, this seems to make sense
16:36:21 <Patrick_H_Lauke> mustaq: there was also a comment from masayuki, but that's a separate issue. he approved the PR, so we can leave that for another issue
16:36:42 <Patrick_H_Lauke> ACTION: mustaq to remove "primary" from https://github.com/w3c/pointerevents/pull/532 and we then merge
16:36:59 <Patrick_H_Lauke> TOPIC: Clarify that click, auxclick and contextmenu get their .button and .buttons behavior from UIEvents https://github.com/w3c/pointerevents/pull/531
16:37:34 <Patrick_H_Lauke> mustaq: approve that an hour ago, looks good to me
16:40:38 <Patrick_H_Lauke> Patrick: I'll massage the wording slightly and then merge
16:40:51 <Patrick_H_Lauke> ACTION: Patrick to tweak and merge https://github.com/w3c/pointerevents/pull/531
16:41:03 <Patrick_H_Lauke> TOPIC: Implicit pointer capture state after a failed explicit capture call at pointerdown https://github.com/w3c/pointerevents/issues/534
16:42:41 <Patrick_H_Lauke> mustaq: implict pointer capture is set by browser, and author can then release or set different capture. what happens if this JS by the author fails?
16:42:58 <Patrick_H_Lauke> Rob: what happens now in general when second capture doesn't work/calls it twice?
16:43:09 <Patrick_H_Lauke> mustaq: then only the first one "takes"
16:43:25 <Patrick_H_Lauke> Rob: so seems consistent
16:43:56 <Patrick_H_Lauke> mustaq: will check if WPT covers this already, if it does i'll close issue, otherwise will comment there and keep open
16:44:12 <Patrick_H_Lauke> ACTION: mustaq to review https://github.com/w3c/pointerevents/issues/534 if it's already covered by WPT
16:44:26 <Patrick_H_Lauke> TOPIC: Define pointermove and pointerrawupdate may have delta from previous corresponding pointer event as movementX and movementY https://github.com/w3c/pointerevents/issues/535
16:46:21 <Patrick_H_Lauke> mustaq: looks reasonable
16:46:23 <Patrick_H_Lauke> Rob: yes
16:46:49 <Patrick_H_Lauke> Patrick: so question - do we want this in v3 or defer. how easy/hard is it to add to our spec? looks like it might involve a lot of extra writing and defining new things
16:47:30 <Patrick_H_Lauke> mustaq: think we don't even mention movementX/movementY in PE spec. so this looks like it'd need a lot of work - ripping it out of mouse event spec
16:47:39 <Patrick_H_Lauke> Rob: not even in mouse event spec, it's an extension to pointer lock spec
16:48:04 <Patrick_H_Lauke> Rob: seems like pointer lock could/should extend pointer event, rather than other way around
16:48:28 <Patrick_H_Lauke> Rob: in the linked section https://w3c.github.io/pointerlock/#extensions-to-the-mouseevent-interface
16:48:52 <Patrick_H_Lauke> Rob: so if pointerlock extended PointerEvent rather than MouseEvent, this would be handled for free
16:50:20 <Patrick_H_Lauke> Rob: pointerevents extend mousevents, but yes it should be defined/mentioned in pointerlock, not in pointervents spec
16:50:37 <Patrick_H_Lauke> mustaq: so we should open an issue against pointerlock, and close the issue at our end?
16:50:48 <Patrick_H_Lauke> Rob: sounds reasonable
16:51:02 <Patrick_H_Lauke> ACTION: mustaq to close/move https://github.com/w3c/pointerevents/issues/535 to pointerlock spec
16:51:13 <Patrick_H_Lauke> TOPIC: Meta-issue: update WPT to cover Pointer Events Level 3 #445 https://github.com/w3c/pointerevents/issues/445
16:51:44 <Patrick_H_Lauke> Patrick: I think nominally we only have one that needs WPT https://github.com/w3c/pointerevents/issues?q=label%3Aneeds-wpt+
16:52:58 <Patrick_H_Lauke> mustaq: this sounds tricky ... related to what we just discussed with pointerlock...
16:57:01 <Patrick_H_Lauke> [discussion on what happens in chrome with dom event change signalling that target needs to be recalculated. might not happen for the events dispatched already in the current tick]
16:57:59 <Patrick_H_Lauke> Rob: want to avoid needing to continuously do hit tests
16:58:27 <Patrick_H_Lauke> mustaq: the ancestor checking couldn't be shipped in chrome due to interop...
16:58:53 <Patrick_H_Lauke> Rob: interop issue not in Firefox though, so it's something in Chrome's implementation
16:59:02 <Patrick_H_Lauke> mustaq: it was some shadow DOM behaviour
16:59:41 <Patrick_H_Lauke> Patrick: so is this realistically something we can look at for v3?
17:00:16 <Patrick_H_Lauke> Rob: we could test state we're currently in - does target change for the move for pointerevents, mousevents, ... if you modify the DOM in events that are synchronously part of the same event stream
17:00:48 <Patrick_H_Lauke> Rob: might be a similar question ... maybe with focus, or similar UI events, that have a similar problem
17:01:10 <Patrick_H_Lauke> Patrick: so something that can be explored for next time?
17:02:03 <Patrick_H_Lauke> Rob: pointerrawupdate i thought the point was that we determine the target from the last non-raw update
17:02:22 <Patrick_H_Lauke> mustaq: because the last raw event may NOT be coalesced
17:02:34 <Patrick_H_Lauke> Rob: does it do a hit test, or take target from the last move?
17:03:05 <Patrick_H_Lauke> mustaq: so it "seems" to be v3 blocking
17:03:45 <Patrick_H_Lauke> Rob: doesn't introduce a new feature, relates to accurately describing current spec behaviour
17:04:47 <Patrick_H_Lauke> ACTION: for next meeting, review https://github.com/w3c/pointerevents/issues/509
17:05:11 <Patrick_H_Lauke> TOPIC: Olli's webcompat issue https://bugzilla.mozilla.org/show_bug.cgi?id=1943411
17:05:21 <Patrick_H_Lauke> Rob: this is the thing we just discussed
17:05:34 <Patrick_H_Lauke> "Masayuki and others analyzed that and he then wrote a patch which mimics Chrome Canary's behavior.
17:05:34 <Patrick_H_Lauke> Release Chrome does something a tiny bit different, I think either the test for mousemove or for the pointer events fail there.
17:05:34 <Patrick_H_Lauke> Tests are in https://phabricator.services.mozilla.com/D235807
17:05:34 <Patrick_H_Lauke> I don't think the specs define too accurately what the behavior should be."
17:05:43 <mustaq> Mozilla change: https://phabricator.services.mozilla.com/D235807
17:05:51 <bkardell_> bkardell_ has joined #pointerevents
17:07:16 <Patrick_H_Lauke> Rob: my intuition is that at the point we generate enter event, we already determined the target of the move
17:07:39 <Patrick_H_Lauke> Rob: pretty sure for enter event we dispatch it to the removed node
17:07:59 <Patrick_H_Lauke> Rob: we could dispatch to the removed node even though you're not supposed to do that (?)
17:08:59 <Patrick_H_Lauke> Rob: ... this is all part of the same problem - we assume that the DOM doesn't change in between these events
17:09:17 <Patrick_H_Lauke> Rob: not a terrible assumption..
17:10:02 <Patrick_H_Lauke> Patrick: apologies, we're over time and i hadn't realised. thank you as ever, catch you in two weeks' time
17:10:12 <Patrick_H_Lauke> rrsagent, make logs world-visible
17:10:17 <Patrick_H_Lauke> rrsagent, generate minutes
17:10:18 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/29-pointerevents-minutes.html Patrick_H_Lauke
18:12:59 <Patrick_H_Lauke> rrsagent, bye
18:12:59 <RRSAgent> I see 6 open action items saved in https://www.w3.org/2025/01/29-pointerevents-actions.rdf :
18:12:59 <RRSAgent> ACTION: Rob to add a small reminder (to ourselves, mainly) what our current thinking/challenges are for https://github.com/w3c/pointerevents/issues/516 [1]
18:12:59 <RRSAgent>   recorded in https://www.w3.org/2025/01/29-pointerevents-irc#T16-19-55
18:12:59 <RRSAgent> ACTION: mustaq to remove "primary" from https://github.com/w3c/pointerevents/pull/532 and we then merge [2]
18:12:59 <RRSAgent>   recorded in https://www.w3.org/2025/01/29-pointerevents-irc#T16-36-42
18:12:59 <RRSAgent> ACTION: Patrick to tweak and merge https://github.com/w3c/pointerevents/pull/531 [3]
18:12:59 <RRSAgent>   recorded in https://www.w3.org/2025/01/29-pointerevents-irc#T16-40-51
18:12:59 <RRSAgent> ACTION: mustaq to review https://github.com/w3c/pointerevents/issues/534 if it's already covered by WPT [4]
18:12:59 <RRSAgent>   recorded in https://www.w3.org/2025/01/29-pointerevents-irc#T16-44-12
18:12:59 <RRSAgent> ACTION: mustaq to close/move https://github.com/w3c/pointerevents/issues/535 to pointerlock spec [5]
18:12:59 <RRSAgent>   recorded in https://www.w3.org/2025/01/29-pointerevents-irc#T16-51-02
18:12:59 <RRSAgent> ACTION: for next meeting, review https://github.com/w3c/pointerevents/issues/509 [6]
18:12:59 <RRSAgent>   recorded in https://www.w3.org/2025/01/29-pointerevents-irc#T17-04-47