15:57:26 <RRSAgent> RRSAgent has joined #pointerevents
15:57:30 <RRSAgent> logging to https://www.w3.org/2023/11/22-pointerevents-irc
15:57:44 <Patrick_H_Lauke> Meeting: PEWG
15:57:47 <Patrick_H_Lauke> Chair: Patrick H. Lauke
15:57:59 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20231122T110000/
15:58:08 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
15:58:20 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
15:58:22 <Patrick_H_Lauke> present+
16:00:24 <Patrick_H_Lauke> present+ smaug
16:01:21 <flackr> flackr has joined #pointerevents
16:01:40 <Patrick_H_Lauke> present+ flackr
16:01:50 <Patrick_H_Lauke> present+ mustaq
16:03:05 <Patrick_H_Lauke> TOPIC: Explain how a removed DOM node should be handled for boundary events https://github.com/w3c/pointerevents/pull/491
16:04:21 <Patrick_H_Lauke> [group agrees this is good to merge for now]
16:05:03 <Patrick_H_Lauke> Rob: i think mustaq has already landed tests for the simple cases
16:05:40 <Patrick_H_Lauke> Rob: have some concerns about this assuming the same event chain / path for all event types
16:06:03 <Patrick_H_Lauke> Rob: "get the parent" algorithm in DOM spec, which can vary by event type
16:06:29 <Patrick_H_Lauke> Rob: we might want to say we use that algo for an event with type pointermove, and standardise on that
16:06:48 <Patrick_H_Lauke> Rob: it's weird that by spec you can have different chain depending on event type
16:07:33 <Patrick_H_Lauke> Mustaq: missing tests relate to slot ...
16:07:52 <mustaq> https://github.com/w3c/pointerevents/issues/477
16:08:24 <Patrick_H_Lauke> Mustaq: ...and shadow dom boundaries
16:09:26 <Patrick_H_Lauke> TOPIC: Clarify mousedown event target if the preceding pointerdown event listener removes the target https://github.com/w3c/pointerevents/issues/492
16:11:38 <Patrick_H_Lauke> 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
16:11:46 <Patrick_H_Lauke> Olli: and what happens if you modify DOM even more
16:12:44 <Patrick_H_Lauke> 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...
16:12:51 <Patrick_H_Lauke> Patrick: event delegation...
16:13:03 <Patrick_H_Lauke> Olli: tricky part is click, because that's not dispatched by any implementation
16:13:24 <Patrick_H_Lauke> Rob: could be accident because we remove the down event, and as result doesn't fire click
16:13:34 <Patrick_H_Lauke> Olli: unfortunate because a dev might expect a click
16:13:44 <Patrick_H_Lauke> Rob: sounds like we may need to do some measurement for this
16:13:53 <Patrick_H_Lauke> Mustaq: i already added WPTs for this
16:14:02 <Patrick_H_Lauke> Mustaq: do we have click there? I forgot...
16:14:17 <Patrick_H_Lauke> Rob: think test wasn't adding a click listener, so we weren't testing for that
16:14:17 <mustaq> https://wpt.fyi/results/pointerevents?label=master&label=experimental&aligned&q=interleaved.tentative.html
16:14:41 <Patrick_H_Lauke> 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
16:15:10 <Patrick_H_Lauke> Mustaq: neither firefox nor chrome fire?
16:15:24 <Patrick_H_Lauke> Rob: firefox, chrome, safari - none of them do
16:15:50 <Patrick_H_Lauke> 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
16:16:07 <Patrick_H_Lauke> Rob: but could be better outcome if we COULD dispatch click
16:16:19 <Patrick_H_Lauke> Mustaq: we can't measure compat impact without trying...
16:16:53 <Patrick_H_Lauke> 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
16:17:13 <Patrick_H_Lauke> Mustaq: ... we can get some estimate
16:17:28 <Patrick_H_Lauke> Rob: we can at least get an estimate, but can't tell if it would break things
16:17:43 <Patrick_H_Lauke> Olli: what happens if you don't REMOVE the target, but just move it to another place in the DOM
16:18:01 <Patrick_H_Lauke> Rob: good point, think we might still dispatch click, and we need to test
16:18:13 <Patrick_H_Lauke> Olli: target would be the same though yes
16:18:40 <Patrick_H_Lauke> Rob: if there's already incompatibility with moved elements...there's an argument to fix this for both removed and moved
16:18:59 <Patrick_H_Lauke> Mustaq: the test ... we check for click, but not sure what outcome is
16:19:19 <Patrick_H_Lauke> Rob: why don't i fork this bin and modify it to check for moved target
16:20:07 <flackr> Moved case https://jsfiddle.net/flackr/grv2956n/5/
16:22:03 <Patrick_H_Lauke> [group tests, and finding different results depending on browser, platform ... inconsistencies]
16:22:18 <mustaq> I am seeing Chrome + Forefox firing click on Linux.
16:22:51 <mustaq> Apparently Chrome on Mac doesn't?!
16:27:32 <Patrick_H_Lauke> Patrick: do we need to do something in our spec, or is this covered elsewhere?
16:28:12 <Patrick_H_Lauke> Rob: probably need to call out the mouse compat events, and that it fires to parent. click event is tricky
16:31:03 <Patrick_H_Lauke> Rob: might be functionally same whether we say it goes to ancestor of pointerdown/pointerup or of the mouse compat ones (?)
16:31:23 <Patrick_H_Lauke> Olli: feels scary potentially firing click where before it didn't, but seems sensible
16:31:43 <Patrick_H_Lauke> Rob: but at least it's a click to the ancestor/higher up, not the elements that have been modified
16:33:19 <Patrick_H_Lauke> Patrick: how easy/hard would it be to patch our spec for this? realistic to say for next meeting?
16:33:23 <Patrick_H_Lauke> Rob: we'll need data
16:33:38 <Patrick_H_Lauke> Patrick: so do we want to delay v3 until this is resolved? or punt this to future?
16:34:06 <Patrick_H_Lauke> 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
16:34:29 <Patrick_H_Lauke> 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
16:34:38 <Patrick_H_Lauke> Mustaq: move not so different from removed
16:34:47 <Patrick_H_Lauke> Rob: moving is remove then add
16:34:59 <Patrick_H_Lauke> Olli: it's question of at which point you check ancestor
16:35:55 <Patrick_H_Lauke> 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)
16:36:57 <Patrick_H_Lauke> Mustaq: in chrome we remember node ...
16:37:15 <Patrick_H_Lauke> Olli: i need to check implementation. we have callback for case where it's removed from DOM and it's definitely called...
16:37:42 <Patrick_H_Lauke> Rob: those are two reasonable options. third option: on removal, we implicitly track nearest thing in the chain that still IS in the DOM
16:38:06 <Patrick_H_Lauke> Rob: because with moving, you could end up firing click to something that didn't originally track the down event, which might be weird
16:38:21 <Patrick_H_Lauke> Olli: guess we need to check the click target
16:39:35 <Patrick_H_Lauke> Mustaq: tricky also if you have capturing on top ... capture on down, then remove the node ... who gets lostpointercapture
16:40:10 <Patrick_H_Lauke> Mustaq: ah no, it never gets resolved
16:40:42 <Patrick_H_Lauke> Olli: i assume you track target on stack somewhere, and then dispatch
16:41:17 <Patrick_H_Lauke> Rob: time delay. question is if we want to keep hold of a reference ...
16:42:44 <Patrick_H_Lauke> 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
16:43:17 <Patrick_H_Lauke> 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
16:47:30 <Patrick_H_Lauke> [further testing]
16:48:13 <Patrick_H_Lauke> 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
16:48:41 <Patrick_H_Lauke> Olli: that works for moving, and for removals... there's a possible web compat issue we need to figure out though
16:48:53 <Patrick_H_Lauke> Rob: need to also work out where in spec this needs to be clarified
16:49:30 <Patrick_H_Lauke> Mustaq: don't think PE spec doesn't define click target, just points to UI Events spec...
16:49:52 <Patrick_H_Lauke> Rob: think the behaviour that Firefox has might already be implied. nothing in spec says forget about down target if node is removed
16:50:08 <Patrick_H_Lauke> Mustaq: UI Event spec doesn't mention anything of that i think
16:50:57 <Patrick_H_Lauke> 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...
16:51:15 <Patrick_H_Lauke> Rob: ... at the time of up ...
16:51:41 <Patrick_H_Lauke> Mustaq: spec doesn't say about the time of up though, so i could interpret it as at the time of down
16:52:00 <Patrick_H_Lauke> Rob: where does spec say that?
16:52:11 <Patrick_H_Lauke> Mustaq: "nearest common inclusive ancestor"
16:52:23 <Patrick_H_Lauke> Mustaq: can have multiple interpretations...
16:52:31 <Patrick_H_Lauke> Rob: we don't want to remember entire ancestor chain
16:52:40 <Patrick_H_Lauke> Mustaq: agree, spec is very handwavy
16:53:24 <Patrick_H_Lauke> 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
16:53:43 <Patrick_H_Lauke> Mustaq: need to agree on behaviour...
16:54:24 <Patrick_H_Lauke> 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 (?)
16:55:22 <Patrick_H_Lauke> Olli: ...spec hints at behaviour that FX has, but it's not very precise...
16:55:34 <Patrick_H_Lauke> Rob: all for standardising on this behaviour and then checking WPT
16:58:44 <Patrick_H_Lauke> [further discussion]
16:59:05 <Patrick_H_Lauke> Rob: it does feel a bit weird, but then we define arguably weird behaviours for other situations
16:59:49 <Patrick_H_Lauke> Olli: there's also still the question about mousedown on removal
17:00:06 <Patrick_H_Lauke> Rob: feels like such an edge case ...
17:00:38 <Patrick_H_Lauke> Mustaq: think PE defines that the compat events should go to ancestor?
17:01:15 <mustaq> "the original target's nearest ancestor node" as per PE spec...
17:02:42 <Patrick_H_Lauke> Olli: we might need to define that click only fires if pointerdown and pointerup are still in DOM
17:03:05 <Patrick_H_Lauke> Rob: prefer looking at it as the ancestor of pointerdown and poitnerup is the same...
17:03:30 <Patrick_H_Lauke> ACTION: Rob to try and write something up in the issue, continue discussion next time
17:04:10 <Patrick_H_Lauke> rrsagent, set logs world-visible
17:04:16 <Patrick_H_Lauke> rrsagent, generate minutes
17:04:17 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/22-pointerevents-minutes.html Patrick_H_Lauke
18:47:54 <Patrick_H_Lauke> Patrick_H_Lauke has left #pointerevents
18:47:59 <Patrick_H_Lauke> Patrick_H_Lauke has joined #pointerevents
18:48:08 <Patrick_H_Lauke> RRSAgent, bye
18:48:08 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2023/11/22-pointerevents-actions.rdf :
18:48:08 <RRSAgent> ACTION: Rob to try and write something up in the issue, continue discussion next time [1]
18:48:08 <RRSAgent>   recorded in https://www.w3.org/2023/11/22-pointerevents-irc#T17-03-30