16:02:03 <RRSAgent> RRSAgent has joined #pointerevents
16:02:07 <RRSAgent> logging to https://www.w3.org/2023/11/08-pointerevents-irc
16:02:08 <Patrick_H_Lauke> Meeting: PEWG
16:02:15 <Patrick_H_Lauke> Chair: Patrick H. Lauke
16:02:27 <Patrick_H_Lauke> Agenda: https://www.w3.org/events/meetings/6246bc85-4dae-43a8-a50c-9bc5a0829585/20231108T110000/
16:02:36 <Patrick_H_Lauke> Scribe: Patrick H. Lauke
16:02:43 <Patrick_H_Lauke> ScribeNick: Patrick_H_Lauke
16:02:53 <Patrick_H_Lauke> present+
16:02:53 <Patrick_H_Lauke> present+ smaug
16:02:59 <Patrick_H_Lauke> present+ flackr
16:03:14 <Patrick_H_Lauke> present+ mustaq
16:04:38 <Patrick_H_Lauke> Patrick: We've been rechartered
16:04:55 <Patrick_H_Lauke> PLH: you don't have to worry, don't have to rejoin, it's all taken care of
16:05:03 <Patrick_H_Lauke> present+ plh
16:05:17 <Patrick_H_Lauke> Topic: Handle pointer capture node removal asynchronously https://github.com/w3c/pointerevents/pull/490
16:06:08 <Patrick_H_Lauke> 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
16:06:21 <Patrick_H_Lauke> Rob: I think we're all good with this one?
16:06:29 <Patrick_H_Lauke> Mustaq: if there's further concerns, we can send more PRs
16:07:01 <Patrick_H_Lauke> 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
16:07:15 <Patrick_H_Lauke> Mustaq: that was another corner case that I originally thought
16:07:31 <mustaq> The PR has been merged.
16:07:46 <Patrick_H_Lauke> Patrick: thank you all for that one
16:07:59 <Patrick_H_Lauke> Topic: Explain how a removed DOM node should be handled for boundary events https://github.com/w3c/pointerevents/pull/491
16:09:24 <Patrick_H_Lauke> 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?
16:09:32 <Patrick_H_Lauke> Rob: but high level, what do we want to do?
16:09:54 <Patrick_H_Lauke> Olli: maybe it wasn't very clear ... that we fire some mouse...over?
16:10:11 <Patrick_H_Lauke> Rob: I could try and clarify, rather than anonymous child ... "as if it was over a child"
16:10:29 <Patrick_H_Lauke> Olli: just because "anonymous child (or something)" was used originally in shadow DOM discussions
16:10:43 <Patrick_H_Lauke> Rob: used it because it's a similar idea ... it's over something that the dev has no access to
16:10:58 <Patrick_H_Lauke> Rob: ... the child is removed, so we can't say "over the deleted child"
16:11:26 <Patrick_H_Lauke> 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
16:12:32 <Patrick_H_Lauke> Patrick: my preference would be "wordier, if it makes it clearer to somebody who's not followed the discussion"
16:12:51 <Patrick_H_Lauke> Rob: I'll expand and use a boolean in the algo. could be like ... "needs over event"
16:13:10 <Patrick_H_Lauke> Rob: and if target is something *other* than we targeted, we can ignore it because it's not needed...
16:13:52 <Patrick_H_Lauke> Olli: [expands on the complexity of child, parent, grandparent, what MAY be behind the actual child that's removed...]
16:14:14 <Patrick_H_Lauke> Rob: all this is handled equivalent to what happens when a child is removed (under the mouse)
16:14:34 <Patrick_H_Lauke> Rob: and that's what this internal tracking state is meant to produce
16:14:51 <Patrick_H_Lauke> Rob: every edge case you can think of, think about what would happen if you removed the child (?)
16:15:55 <Patrick_H_Lauke> 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"
16:16:14 <Patrick_H_Lauke> Rob: with caveat that we drop any events targeted at deleted child, because they're not meant to be dispatched
16:16:34 <Patrick_H_Lauke> ACTION: Rob to expand https://github.com/w3c/pointerevents/pull/491 further/wordier, others to review for next meeting
16:17:08 <Patrick_H_Lauke> Patrick: just circling back to https://github.com/w3c/pointerevents/pull/490 do we need a WPT?
16:17:46 <Patrick_H_Lauke> Rob: i think this only clarifies existing behaviour. unless we want to test the async vs sync
16:18:05 <Patrick_H_Lauke> Mustaq: ... i think we had a test about existing capture ...
16:18:25 <Patrick_H_Lauke> 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
16:18:38 <mustaq> pointerevent_lostpointercapture_for_disconnected_node.html
16:19:01 <Patrick_H_Lauke> Mustaq: there is a test (link above), not sure if it passes
16:19:12 <Patrick_H_Lauke> Mustaq: tests wether event is fired, but not the timing
16:21:29 <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:21:43 <Patrick_H_Lauke> Olli: background here is the interop
16:21:56 <Patrick_H_Lauke> Olli: unclear what you do from interop point of view
16:22:45 <Patrick_H_Lauke> 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
16:23:00 <Patrick_H_Lauke> Mustaq: added a tentative test. not part of this year's interop, maybe next
16:23:37 <Patrick_H_Lauke> Olli: i think chrome's behaviour here is reasonable, but I can also see the logic in the opposite approach
16:24:22 <Patrick_H_Lauke> Mustaq: one difference is that chrome doesn't send click...
16:24:54 <Patrick_H_Lauke> Rob: does Firefox send click?
16:25:43 <Patrick_H_Lauke> 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...
16:26:15 <Patrick_H_Lauke> Rob: we could treat it like boundary change... I can make tests where both behaviours are reasonable
16:26:29 <Patrick_H_Lauke> Rob: state of the DOM is state of the up dispatch
16:26:46 <Patrick_H_Lauke> Olli: but what is the state of the down... is it the common ancestor, etc
16:27:05 <Patrick_H_Lauke> Mustaq: common ancestor of UNDEFINED is also a possibility. UI spec doesn't say...
16:27:19 <Patrick_H_Lauke> Rob: equally if you keep ref to deleted node, the common ancestor doesn't exist
16:27:29 <Patrick_H_Lauke> Mustaq: i'm sure we've had the current behaviour because of a bug
16:27:53 <Patrick_H_Lauke> Rob: I can think of cases where it'll be weird for developers. Many cases where React keeps track of nodes...
16:28:13 <Patrick_H_Lauke> Mustaq: Rob could you add that in the issue, so we don't forget
16:28:49 <Patrick_H_Lauke> Olli: historically, when you had mousedown and mouseup, you'd always get a click...but now it's trickier. I *would* expect click
16:28:57 <Patrick_H_Lauke> Rob: same, unless we can find strong reason why not
16:29:33 <Patrick_H_Lauke> Patrick: so is this a blocker for v3?
16:29:52 <Patrick_H_Lauke> Rob: two things: click dispatch and should there ever be a difference between pointer event dispatch and mouse event dispatch...
16:30:11 <Patrick_H_Lauke> 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
16:30:16 <Patrick_H_Lauke> Rob: I don't like that too much
16:30:22 <mustaq> I am adding a tentative WPT for this issue here: https://chromium-review.googlesource.com/c/chromium/src/+/5008504
16:30:29 <Patrick_H_Lauke> Olli: it'd be weird because you'd still get mouseup later, yes
16:30:58 <Patrick_H_Lauke> Rob: i'll add comment to the issue explaining what sub issues are
16:31:34 <Patrick_H_Lauke> 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...
16:31:40 <Patrick_H_Lauke> Mustaq: it's a pointer event now though
16:31:47 <Patrick_H_Lauke> Rob: but also happy to specify both things
16:33:13 <Patrick_H_Lauke1> Patrick_H_Lauke1 has joined #pointerevents
16:33:18 <Patrick_H_Lauke1> Mustaq: compatibility risk?
16:33:57 <Patrick_H_Lauke1> (not sure what happened with my user here...must have clicked something, or due to my connection crapping out)
16:35:07 <Patrick_H_Lauke1> ACTION: Rob to investigate further / write up rationale
16:35:37 <Patrick_H_Lauke1> Patrick: just checking if there's any other blocking issues https://github.com/w3c/pointerevents/issues?q=is%3Aissue+is%3Aopen+label%3Av3-blocking
16:38:09 <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
16:38:21 <Patrick_H_Lauke1> Patrick: thank you all, we'll reconvene in 2 weeks
16:38:27 <Patrick_H_Lauke1> RRSAgent, set logs world-visible
16:38:34 <Patrick_H_Lauke1> RRSAgent, create minutes
16:38:36 <RRSAgent> I have made the request to generate https://www.w3.org/2023/11/08-pointerevents-minutes.html Patrick_H_Lauke1
16:38:58 <Patrick_H_Lauke1> RRSAgent, bye
16:38:58 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2023/11/08-pointerevents-actions.rdf :
16:38:58 <RRSAgent> ACTION: Rob to expand https://github.com/w3c/pointerevents/pull/491 further/wordier, others to review for next meeting [1]
16:38:58 <RRSAgent>   recorded in https://www.w3.org/2023/11/08-pointerevents-irc#T16-16-34
16:38:58 <RRSAgent> ACTION: Rob to investigate further / write up rationale [2]
16:38:58 <RRSAgent>   recorded in https://www.w3.org/2023/11/08-pointerevents-irc#T16-35-07