Meeting minutes
Explain how a removed DOM node should be handled for boundary events w3c/pointerevents#491
[group agrees this is good to merge for now]
Rob: i think mustaq has already landed tests for the simple cases
Rob: have some concerns about this assuming the same event chain / path for all event types
Rob: "get the parent" algorithm in DOM spec, which can vary by event type
Rob: we might want to say we use that algo for an event with type pointermove, and standardise on that
Rob: it's weird that by spec you can have different chain depending on event type
Mustaq: missing tests relate to slot ...
<mustaq> w3c/
Mustaq: ...and shadow dom boundaries
Clarify mousedown event target if the preceding pointerdown event listener removes the target w3c/pointerevents#492
Rob: tricky part here is when you have a pointer event and compat mouse event dispatched. when PE removes target, does it affect the mouse compat target
Olli: and what happens if you modify DOM even more
Rob: i'm in favour to having it behave similar to tracking what pointer is over - goes to the parent. think there's a lot of pages which ... things like React replace large chunks of inner elements, but want to still fire to ancestor...
Patrick: event delegation...
Olli: tricky part is click, because that's not dispatched by any implementation
Rob: could be accident because we remove the down event, and as result doesn't fire click
Olli: unfortunate because a dev might expect a click
Rob: sounds like we may need to do some measurement for this
Mustaq: i already added WPTs for this
Mustaq: do we have click there? I forgot...
Rob: think test wasn't adding a click listener, so we weren't testing for that
Rob: we probably need to add some metrics to see how often we're going to be dispatching click for something removed in the pointerdown
Mustaq: neither firefox nor chrome fire?
Rob: firefox, chrome, safari - none of them do
Rob: we could say that if the down element is removed, the click isn't dispatched - if it's too late for us to change this
Rob: but could be better outcome if we COULD dispatch click
Mustaq: we can't measure compat impact without trying...
Rob: not necessarily, can measure how often we currently DON'T fire a click because the down element was removed. can further determine what the target of the click would be, and check if ancestor has a click handler
Mustaq: ... we can get some estimate
Rob: we can at least get an estimate, but can't tell if it would break things
Olli: what happens if you don't REMOVE the target, but just move it to another place in the DOM
Rob: good point, think we might still dispatch click, and we need to test
Olli: target would be the same though yes
Rob: if there's already incompatibility with moved elements...there's an argument to fix this for both removed and moved
Mustaq: the test ... we check for click, but not sure what outcome is
Rob: why don't i fork this bin and modify it to check for moved target
<flackr> Moved case https://
[group tests, and finding different results depending on browser, platform ... inconsistencies]
<mustaq> I am seeing Chrome + Forefox firing click on Linux.
<mustaq> Apparently Chrome on Mac doesn't?!
Patrick: do we need to do something in our spec, or is this covered elsewhere?
Rob: probably need to call out the mouse compat events, and that it fires to parent. click event is tricky
Rob: might be functionally same whether we say it goes to ancestor of pointerdown/pointerup or of the mouse compat ones (?)
Olli: feels scary potentially firing click where before it didn't, but seems sensible
Rob: but at least it's a click to the ancestor/higher up, not the elements that have been modified
Patrick: how easy/hard would it be to patch our spec for this? realistic to say for next meeting?
Rob: we'll need data
Patrick: so do we want to delay v3 until this is resolved? or punt this to future?
Rob: i'd be ok leaning to: if target removed from DOM since the down event, before the up event, we don't fire click
Rob: in terms of something less likely to break things. but it will be a change, as in the moved case we do see clicks
Mustaq: move not so different from removed
Rob: moving is remove then add
Olli: it's question of at which point you check ancestor
Rob: if we're worried about compat of clicks being fired where they weren't being fired before, then my suggestion is the above (if target removed since down but before up, don't fire click)
Mustaq: in chrome we remember node ...
Olli: i need to check implementation. we have callback for case where it's removed from DOM and it's definitely called...
Rob: those are two reasonable options. third option: on removal, we implicitly track nearest thing in the chain that still IS in the DOM
Rob: because with moving, you could end up firing click to something that didn't originally track the down event, which might be weird
Olli: guess we need to check the click target
Mustaq: tricky also if you have capturing on top ... capture on down, then remove the node ... who gets lostpointercapture
Mustaq: ah no, it never gets resolved
Olli: i assume you track target on stack somewhere, and then dispatch
Rob: time delay. question is if we want to keep hold of a reference ...
Olli: presumably, at high level, on pointerdown you check target, and then immediately/in the same task also fire mousedown, without even checking again right away
Rob: whether we keep track of that target until we see the up event... chrome does, based on test results, but we need to define this
[further testing]
Rob: tracking element that we dispatched the down to is more useful, as it supports the reordering case i linked the bug for. maybe we can try to resolve on that
Olli: that works for moving, and for removals... there's a possible web compat issue we need to figure out though
Rob: need to also work out where in spec this needs to be clarified
Mustaq: don't think PE spec doesn't define click target, just points to UI Events spec...
Rob: think the behaviour that Firefox has might already be implied. nothing in spec says forget about down target if node is removed
Mustaq: UI Event spec doesn't mention anything of that i think
Rob: through that, you hold on to the element of the down event, and use that to check ancestor. if node removed, it won't have an ancestor...
Rob: ... at the time of up ...
Mustaq: spec doesn't say about the time of up though, so i could interpret it as at the time of down
Rob: where does spec say that?
Mustaq: "nearest common inclusive ancestor"
Mustaq: can have multiple interpretations...
Rob: we don't want to remember entire ancestor chain
Mustaq: agree, spec is very handwavy
Rob: we could add a few words here like: when the mouseup event is dispatched, compute the common ancestor of the down target and the up target in the current state of the DOM, or something to that effect
Mustaq: need to agree on behaviour...
Rob: UI Events spec also seems to say we *shouldn't* fire click... oh, doesn't say anything about not firing the event, just not to the same target (?)
Olli: ...spec hints at behaviour that FX has, but it's not very precise...
Rob: all for standardising on this behaviour and then checking WPT
[further discussion]
Rob: it does feel a bit weird, but then we define arguably weird behaviours for other situations
Olli: there's also still the question about mousedown on removal
Rob: feels like such an edge case ...
Mustaq: think PE defines that the compat events should go to ancestor?
<mustaq> "the original target's nearest ancestor node" as per PE spec...
Olli: we might need to define that click only fires if pointerdown and pointerup are still in DOM
Rob: prefer looking at it as the ancestor of pointerdown and poitnerup is the same...
ACTION: Rob to try and write something up in the issue, continue discussion next time