Meeting minutes
same
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://
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://
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/
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...