- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 12 Feb 2025 16:56:29 +0000
- To: public-pointer-events@w3.org
Dear all, the minutes for today's meeting are at https://www.w3.org/2025/02/12-pointerevents-minutes.html and copied below (with apologies, forgot to do the "present+" for folks, so manually filling that in here in the email only): PEWG 12 February 2025 Agenda: https://www.w3.org/events/meetings/66591f6b-6694-4f90-b23d-bf8f1b9dda8a/20250212T110000/ IRC log: https://www.w3.org/2025/02/12-pointerevents-irc Attendees: Patrick, Rob, Olli, Mustaq, Adam Chair: Patrick H. Lauke Scribe: Patrick H. Lauke * Clarify the event target of pointermove if an event listener of the preceding pointerrawupdate explicitly release pointer capture w3c/pointerevents#509 * Define pointermove and pointerrawupdate may have delta from previous corresponding pointer event as movementX and movementY w3c/pointerevents#535 * Clarify pointermove event (or following event of pointer boundary events) target if preceding pointer boundary event listener removes the pointerover target w3c/pointerevents#536 * Define pointermove and pointerrawupdate may have delta from previous corresponding pointer event as movementX and movementY w3c/pointerevents#535 (redux) * Implicit pointer capture state after a failed explicit capture call at pointerdown w3c/pointerevents#534 # Clarify the event target of pointermove if an event listener of the preceding pointerrawupdate explicitly release pointer capture w3c/pointerevents#509 Olli: was discussing with Masayuki last night, agreed to close Olli: somebody will need to do WPT ? Define pointermove and pointerrawupdate may have delta from previous corresponding pointer event as movementX and movementY w3c/pointerevents#535 Patrick: I see a comment from Olli that this is a dupe on pointerlock Olli: right now it's clear that movement should be zero, but because they're not in all implementations... Olli: not sure what webkit does here Olli: isn't mustaq also editor for pointerlock? Patrick: he is yes https://w3c.github.io/pointerlock/ Olli: type is actually double, so not sure what Masayuki means... Olli: unless you can remember, Rob, if these are actually "long" Rob: I think there'd be far less compat risk though either way 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? Rob: yes, that's fine, it should just be covered by pointerlock <mustaq> (sorry having a computer issue, still trying to join) ACTION: keep #535 open, but action is on pointerlock spec to deal with # Clarify pointermove event (or following event of pointer boundary events) target if preceding pointer boundary event listener removes the pointerover target w3c/pointerevents#536 Olli: mouse event handling was causing some weird webcompat issues Olli: what should happen if you remove the move target when dealing with boundary events Olli: but with pointer events all browsers do same Olli: so question is if we (firefox) want to do the same as chrome canary Olli: and Safari does something weird/idiosyncratic 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? Olli: though we may still be the people that decide what should happen for UIEvents... Olli: unless Rob remembers any specifics... Rob: I'd have to refresh my memory on this, it's a bit hazy Mustaq: is this pointermove, or mousemove? Olli: both, there's divergence in behaviour (looking at latest chrome canary) 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 Mustaq: all browsers drop pointermove? Olli: yes, though from Masayuki's comment it looks like sometimes it does go to document or window 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) Rob: what is the higher level change? during async dispatches, events go to the still attached ancestor? Olli: yes Rob: same as we did for DISPATCHING the boundary events Rob: seems reasonable... Olli: webcompat story will be difficult, as right now all browsers DO the same (drop the pointermove altogether?) Olli: could do with some telemetry... 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 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 Mustaq: you mentioned you faced some broken sites? Olli: that was with *mouse events* <smaug> https://bugzilla.mozilla.org/show_bug.cgi?id=1943411 Olli: that has link to the relevant site. menu bar was broken because they were rebuilding menu structure when you were moving mouse Olli: we had that behaviour enabled in nightly for some time, but only realised when it went to beta Olli: we all agree though that we SHOULD try to dispatch pointermove Patrick: so do we need anything in our spec? 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 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? 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 Olli: UIEvents... Rob: but *this* part of mouse events will be subsumed by pointer events in the long run Mustaq: maybe adding a line in pointer events, even if we mark it as at risk somehow.... Olli: this could be for PE next Patrick: so we can leave it to the side for v3? it's edge-casey... ACTION: mark issue for Next # Define pointermove and pointerrawupdate may have delta from previous corresponding pointer event as movementX and movementY w3c/pointerevents#535 (redux) 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? Mustaq: yes, makes sense # Implicit pointer capture state after a failed explicit capture call at pointerdown w3c/pointerevents#534 Patrick: PR looks good to my naive eyes (assuming this matches reality), but leaving the actual review to Olli/Rob Mustaq: it matches reality insofar as it matches what the algorithm says should happen Rob: it looks fine to me Olli: looks fine to me ACTION: merge PR Mustaq: i have additional point for interop 2025 <mustaq> Interop 2025 Pointer/Mouse: web-platform-tests/interop#809 Mustaq: proposed a few WPTs relating to pointer events. would be good to get Mozilla's take/help on these Olli: `uievents/mouse/mousemove_after_mouseover_target_removed.html` looks like what we discussed earlier Mustaq: feel free to push back, propose yours... these seem easy/manageable <mustaq> Any comment there from Mozilla would be appreciated. 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... # Summary of action items * keep #535 open, but action is on pointerlock spec to deal with * mark issue for Next * merge PR -- Patrick H. Lauke * https://www.splintered.co.uk/ * https://github.com/patrickhlauke * https://flickr.com/photos/redux/ * https://mastodon.social/@patrick_h_lauke
Received on Wednesday, 12 February 2025 16:56:36 UTC