16:00:21 <RRSAgent> RRSAgent has joined #pointerevents
16:00:25 <RRSAgent> logging to https://www.w3.org/2025/02/12-pointerevents-irc
16:00:27 <Patrick_H_Lauke> same
16:02:05 <Patrick_H_Lauke> Meeting: PEWG
16:02:10 <Patrick_H_Lauke> Chair: Patrick H. Lauke
16:02:33 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/66591f6b-6694-4f90-b23d-bf8f1b9dda8a/20250212T110000/
16:02:42 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
16:02:51 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
16:05:29 <Patrick_H_Lauke> TOPIC: Clarify the event target of pointermove if an event listener of the preceding pointerrawupdate explicitly release pointer capture https://github.com/w3c/pointerevents/issues/509
16:05:56 <Patrick_H_Lauke> Olli: was discussing with Masayuki last night, agreed to close
16:06:19 <Patrick_H_Lauke> Olli: somebody will need to do WPT ?
16:06:43 <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:07:21 <Patrick_H_Lauke> Patrick: I see a comment from Olli that this is a dupe on pointerlock
16:07:49 <Patrick_H_Lauke> Olli: right now it's clear that movement should be zero, but because they're not in all implementations...
16:07:54 <Patrick_H_Lauke> Olli: not sure what webkit does here
16:08:27 <Patrick_H_Lauke> Olli: isn't mustaq also editor for pointerlock?
16:08:51 <Patrick_H_Lauke> Patrick: he is yes https://w3c.github.io/pointerlock/
16:09:31 <Patrick_H_Lauke> Olli: type is actually double, so not sure what Masayuki means...
16:10:02 <Patrick_H_Lauke> Olli: unless you can remember, Rob, if these are actually "long"
16:10:15 <Patrick_H_Lauke> Rob: I think there'd be far less compat risk though either way
16:11:38 <Patrick_H_Lauke> Patrick: so do we need to do anything here? PE extend mouse events, and pointerlock extends mouse events, so it's fine we don't cover movementX/Y in ours?
16:11:49 <Patrick_H_Lauke> Rob: yes, that's fine, it should just be covered by pointerlock
16:13:52 <mustaq> (sorry having a computer issue, still trying to join)
16:14:12 <Patrick_H_Lauke> ACTION: keep #535 open, but action is on pointerlock spec to deal with
16:14:31 <Patrick_H_Lauke> TOPIC: Clarify pointermove event (or following event of pointer boundary events) target if preceding pointer boundary event listener removes the pointerover target https://github.com/w3c/pointerevents/issues/536
16:15:30 <Patrick_H_Lauke> Olli: mouse event handling was causing some weird webcompat issues
16:16:01 <Patrick_H_Lauke> Olli: what should happen if you remove the move target when dealing with boundary events
16:16:20 <Patrick_H_Lauke> Olli: but with pointer events all browsers do same
16:16:44 <Patrick_H_Lauke> Olli: so question is if we (firefox) want to do the same as chrome canary
16:17:05 <Patrick_H_Lauke> Olli: and Safari does something weird/idiosyncratic
16:19:19 <Patrick_H_Lauke> Patrick: so reading between the lines, is this issue a case of "wait to see what UIEvents decide for mouse events, and THEN pointer events should match the behaviour?" as in not for us to do anything right now?
16:19:37 <Patrick_H_Lauke> Olli: though we may still be the people that decide what should happen for UIEvents...
16:19:53 <Patrick_H_Lauke> Olli: unless Rob remembers any specifics...
16:20:17 <Patrick_H_Lauke> Rob: I'd have to refresh my memory on this, it's a bit hazy
16:20:25 <Patrick_H_Lauke> Mustaq: is this pointermove, or mousemove?
16:20:49 <Patrick_H_Lauke> Olli: both, there's divergence in behaviour (looking at latest chrome canary)
16:21:15 <Patrick_H_Lauke> Olli: you would dispatch mousemove to nearest ancestor. right now when dealing with pointer events the pointermove is just GONE. so that's the difference
16:21:27 <Patrick_H_Lauke> Mustaq: all browsers drop pointermove?
16:22:03 <Patrick_H_Lauke> Olli: yes, though from Masayuki's comment it looks like sometimes it does go to document or window
16:22:39 <Patrick_H_Lauke> Rob: for an author, you listen on some ancestor, and it would be strange not to get that event when some deep child node fired it. so i think we should TRY to dispatch the event (pointermove)
16:23:46 <Patrick_H_Lauke> Rob: what is the higher level change? during async dispatches, events go to the still attached ancestor?
16:23:48 <Patrick_H_Lauke> Olli: yes
16:23:59 <Patrick_H_Lauke> Rob: same as we did for DISPATCHING the boundary events
16:24:05 <Patrick_H_Lauke> Rob: seems reasonable...
16:24:32 <Patrick_H_Lauke> Olli: webcompat story will be difficult, as right now all browsers DO the same (drop the pointermove altogether?)
16:24:41 <Patrick_H_Lauke> Olli: could do with some telemetry...
16:25:13 <Patrick_H_Lauke> Rob: we could add counter - implement new behaviour, and then check if there are any move event listeners on ancestors when a target has changed
16:25:39 <Patrick_H_Lauke> Rob: more inclined to just make change and see if we get complaints. know it's risky, but such an edge case that we can't accurately measure impact beforehand
16:25:50 <Patrick_H_Lauke> Mustaq: you mentioned you faced some broken sites?
16:26:04 <Patrick_H_Lauke> Olli: that was with *mouse events*
16:26:23 <smaug> https://bugzilla.mozilla.org/show_bug.cgi?id=1943411
16:26:49 <Patrick_H_Lauke> Olli: that has link to the relevant site. menu bar was broken because they were rebuilding menu structure when you were moving mouse
16:27:13 <Patrick_H_Lauke> Olli: we had that behaviour enabled in nightly for some time, but only realised when it went to beta
16:27:58 <Patrick_H_Lauke> Olli: we all agree though that we SHOULD try to dispatch pointermove
16:28:38 <Patrick_H_Lauke> Patrick: so do we need anything in our spec?
16:29:14 <Patrick_H_Lauke> Rob: behaviour is going to be that: we have movement, we determine a target, and if as result of boundary events something happens, we still try to dispatch to an ancestor
16:30:30 <Patrick_H_Lauke> Mustaq: it follows our general approach of "if a node disappears, we still try to fire the events to ancestors if possible". does any other spec clarify this?
16:30:50 <Patrick_H_Lauke> Rob: I don't think other specs have looked at DOM modifications as deeply as we have, so we may have to pave the path
16:31:14 <Patrick_H_Lauke> Olli: UIEvents...
16:31:28 <Patrick_H_Lauke> Rob: but *this* part of mouse events will be subsumed by pointer events in the long run
16:31:52 <Patrick_H_Lauke> Mustaq: maybe adding a line in pointer events, even if we mark it as at risk somehow....
16:32:00 <Patrick_H_Lauke> Olli: this could be for PE next
16:33:56 <Patrick_H_Lauke> Patrick: so we can leave it to the side for v3? it's edge-casey...
16:34:29 <Patrick_H_Lauke> ACTION: mark issue for Next
16:35:19 <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 (redux)
16:38:09 <Patrick_H_Lauke> Patrick: for context Mustaq, we came to the point of saying "PE extends mouse, pointer lock extends mouse, so it's fine we don't explicitly mention movementX/Y in our spec". does that make sense, since you're also an editor of pointerlock?
16:38:14 <Patrick_H_Lauke> Mustaq: yes, makes sense
16:38:30 <Patrick_H_Lauke> TOPIC: Implicit pointer capture state after a failed explicit capture call at pointerdown https://github.com/w3c/pointerevents/issues/534
16:41:47 <Patrick_H_Lauke> Patrick: PR looks good to my naive eyes (assuming this matches reality), but leaving the actual review to Olli/Rob
16:42:00 <Patrick_H_Lauke> Mustaq: it matches reality insofar as it matches what the algorithm says should happen
16:42:44 <Patrick_H_Lauke> Rob: it looks fine to me
16:43:12 <Patrick_H_Lauke> Olli: looks fine to me
16:44:51 <Patrick_H_Lauke> ACTION: merge PR
16:45:06 <Patrick_H_Lauke> Mustaq: i have additional point for interop 2025
16:45:15 <mustaq> Interop 2025 Pointer/Mouse: https://github.com/web-platform-tests/interop/issues/809
16:46:10 <Patrick_H_Lauke> Mustaq: proposed a few WPTs relating to pointer events. would be good to get Mozilla's take/help on these
16:46:55 <Patrick_H_Lauke> Olli: `uievents/mouse/mousemove_after_mouseover_target_removed.html` looks like what we discussed earlier
16:47:58 <Patrick_H_Lauke> Mustaq: feel free to push back, propose yours... these seem easy/manageable
16:49:39 <mustaq> Any comment there from Mozilla would be appreciated.
16:51:22 <Patrick_H_Lauke> Patrick: thank you all, this concludes today's meeting. I will look at any cherry-picking of PRs that were made to main branch that SHOULD also go to v3, and i think we're now close to calling v3 ready for next stage of REC track...
16:51:31 <Patrick_H_Lauke> rrsagent, set logs world-visible
16:51:35 <Patrick_H_Lauke> rrsagent, generate minutes
16:51:36 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/12-pointerevents-minutes.html Patrick_H_Lauke
16:51:54 <Patrick_H_Lauke> rrsagent, bye
16:51:54 <RRSAgent> I see 3 open action items saved in https://www.w3.org/2025/02/12-pointerevents-actions.rdf :
16:51:54 <RRSAgent> ACTION: keep #535 open, but action is on pointerlock spec to deal with [1]
16:51:54 <RRSAgent>   recorded in https://www.w3.org/2025/02/12-pointerevents-irc#T16-14-12
16:51:54 <RRSAgent> ACTION: mark issue for Next [2]
16:51:54 <RRSAgent>   recorded in https://www.w3.org/2025/02/12-pointerevents-irc#T16-34-29
16:51:54 <RRSAgent> ACTION: merge PR [3]
16:51:54 <RRSAgent>   recorded in https://www.w3.org/2025/02/12-pointerevents-irc#T16-44-51