Meeting minutes
Patrick: We've been rechartered
PLH: you don't have to worry, don't have to rejoin, it's all taken care of
Handle pointer capture node removal asynchronously w3c/pointerevents#490
Rob: I put together the rough idea we threw around before - not sending synchronous events when DOM updated. now relying on async pointer capture that we send with the regular dispatch
Rob: I think we're all good with this one?
Mustaq: if there's further concerns, we can send more PRs
Rob: we can always refine, but this is close to what we want. and don't have to worry about setting pointer state to document, as document doesn't have setPointerCapture, so can't do it
Mustaq: that was another corner case that I originally thought
<mustaq> The PR has been merged.
Patrick: thank you all for that one
Explain how a removed DOM node should be handled for boundary events w3c/pointerevents#491
Rob: having trouble wording this. we know what it should do, but we don't want to redefine things that should be defined elsewhere. like path, TECHNICALLY depends on event type, but for our events it's always the same. would be a problem later if UI events at some point defined a different path for different event types?
Rob: but high level, what do we want to do?
Olli: maybe it wasn't very clear ... that we fire some mouse...over?
Rob: I could try and clarify, rather than anonymous child ... "as if it was over a child"
Olli: just because "anonymous child (or something)" was used originally in shadow DOM discussions
Rob: used it because it's a similar idea ... it's over something that the dev has no access to
Rob: ... the child is removed, so we can't say "over the deleted child"
Rob: I can just make this wordier, maybe there's a boolean whether it's over the parent, or something like that. reflect it in the algorithm
Patrick: my preference would be "wordier, if it makes it clearer to somebody who's not followed the discussion"
Rob: I'll expand and use a boolean in the algo. could be like ... "needs over event"
Rob: and if target is something *other* than we targeted, we can ignore it because it's not needed...
Olli: [expands on the complexity of child, parent, grandparent, what MAY be behind the actual child that's removed...]
Rob: all this is handled equivalent to what happens when a child is removed (under the mouse)
Rob: and that's what this internal tracking state is meant to produce
Rob: every edge case you can think of, think about what would happen if you removed the child (?)
Rob: I'll remove anonymous child and replace with stateful value/boolen. also add explanation that the idea here is same as "what happens if you remove the child on the next pointermove"
Rob: with caveat that we drop any events targeted at deleted child, because they're not meant to be dispatched
ACTION: Rob to expand w3c/
Patrick: just circling back to w3c/
Rob: i think this only clarifies existing behaviour. unless we want to test the async vs sync
Mustaq: ... i think we had a test about existing capture ...
Rob: only additional test i can think of is that dispatch doesn't happen sync. so you remove node and test if event listener had been called
<mustaq> pointerevent_lostpointercapture_for_disconnected_node.html
Mustaq: there is a test (link above), not sure if it passes
Mustaq: tests wether event is fired, but not the timing
Clarify mousedown event target if the preceding pointerdown event listener removes the target w3c/pointerevents#492
Olli: background here is the interop
Olli: unclear what you do from interop point of view
Mustaq: i'm changing interop test to only have pointer, and a separate one for mouse. problem in current interop test is that we mix the two
Mustaq: added a tentative test. not part of this year's interop, maybe next
Olli: i think chrome's behaviour here is reasonable, but I can also see the logic in the opposite approach
Mustaq: one difference is that chrome doesn't send click...
Rob: does Firefox send click?
Rob: currently you can say at point of mouseup, we check common ancestor, and see there is no common ancestor because the node's been removed...
Rob: we could treat it like boundary change... I can make tests where both behaviours are reasonable
Rob: state of the DOM is state of the up dispatch
Olli: but what is the state of the down... is it the common ancestor, etc
Mustaq: common ancestor of UNDEFINED is also a possibility. UI spec doesn't say...
Rob: equally if you keep ref to deleted node, the common ancestor doesn't exist
Mustaq: i'm sure we've had the current behaviour because of a bug
Rob: I can think of cases where it'll be weird for developers. Many cases where React keeps track of nodes...
Mustaq: Rob could you add that in the issue, so we don't forget
Olli: historically, when you had mousedown and mouseup, you'd always get a click...but now it's trickier. I *would* expect click
Rob: same, unless we can find strong reason why not
Patrick: so is this a blocker for v3?
Rob: two things: click dispatch and should there ever be a difference between pointer event dispatch and mouse event dispatch...
Olli: if we always follow pointer event dispatch, there won't be a mousedown because the node is gone, so there would not be a click
Rob: I don't like that too much
<mustaq> I am adding a tentative WPT for this issue here: https://
Olli: it'd be weird because you'd still get mouseup later, yes
Rob: i'll add comment to the issue explaining what sub issues are
Rob: relation between pointer event and mouse event and what happens when a node is removed. click dispatch is not so strong, because it's more a UI event...
Mustaq: it's a pointer event now though
Rob: but also happy to specify both things
<Patrick_H_Lauke1> Mustaq: compatibility risk?
<Patrick_H_Lauke1> (not sure what happened with my user here...must have clicked something, or due to my connection crapping out)
ACTION: Rob to investigate further / write up rationale
<Patrick_H_Lauke1> Patrick: just checking if there's any other blocking issues https://
<Patrick_H_Lauke1> Patrick: I'd say concentrate on the remaining blockers, WPTs after, so we can send for wide review with all normative changes in
<Patrick_H_Lauke1> Patrick: thank you all, we'll reconvene in 2 weeks