W3C

– DRAFT –
PEWG

20 December 2023

Attendees

Present
flackr, mustaq, smaug
Regrets
-
Chair
Patrick H. Lauke
Scribe
Patrick H. Lauke, Patrick_H_Lauke

Meeting minutes

<flackr> https://bugs.chromium.org/p/chromium/issues/detail?id=269917#c49

[group briefly discussed an interesting interop issue they came across - some browsers "soft-capturing" mouse events to a particular window/frame on mousedown, so can't drag/drop between frames; firefox and safari do it, chrome doesn't. differences across platforms. possibly cross-origin differences. might not be pointer events specific, more generally UI events, as this is undefined behaviour]

<mustaq> The drag out of window causing reversed typing: https://crbug.com/1402816

[decided group may tackle this aspect to spec in future, even though this may need to then seep into UI events]

Clarify mousedown event target if the preceding pointerdown event listener removes the target #492 w3c/pointerevents#492

Mustaq: was hoping to write a PR for this week, but will happen in new year

Patrick: after that, we will then submit for wide review, once all normative changes are in the spec and it's "complete" for v3

Meta-issue: update WPT to cover Pointer Events Level 3 #445 w3c/pointerevents#445

Olli: we have 6

Olli: wonder if we can go through these in the new year and just settle them

Mustaq: just need some time. when are we next meeting

Patrick: we next meet on 17 January (I have next two weeks off)

Patrick: will send reminder earlier

Rob: we also have weirdness with DOM modification (e.g. lostPointerCapture etc when node is removed). don't have concrete proposal, but our naive assumption that we resolve on next pointer event doesn't quite work on that case

Rob: not sure it needs spec change, but need to verify that what we expect to happen happens correctly ?

Rob: if during lostPointerCapture of the previous element, or gotPointerCapture of the new element, and then the element is removed...

Rob: we don't like sending events to targets that are removed...but we should talk about it some more

Rob: if the event is not going to the new capture target, where IS it going

Rob: don't want to drop the event, but need to decide who gets it

Rob: i landed a WPT that tests what i think is the expected behaviour. will file an issue to see if there's agreement

<mustaq> The WPT Rob is landing now: https://chromium-review.googlesource.com/c/chromium/src/+/5053186

Olli: might be one of the cases where none of the browsers are consistent/do what we'd expect

Rob: there's also other oddities, like boundary events and elements are removed, we still send boundary events. may need to say we snapshot

Mustaq: snapshot but don't send the event...

Rob: ...every browser sends it to the full chain, including the removed nodes

Rob: this doesn't seem at all PE specific, just a bunch of edge cases that should have been covered in UI events...

Rob: capture is weird because it gives you a chance to change the DOM before the events come in, so you potentially send events to a removed node

Olli: hit testing should be specified...

Rob: none of this is contingent on hit testing. assuming there IS a consistent-enough hit testing, THEN what should we do...

Patrick: thank you all, as ever. Once we have the last issue for v3 resolved, we'll finally be able to draw a line under PE3, and then regroup to see where we want to take this after that (e.g. living standard). in the meantime, have a good break, and we'll reconvene on the 17 January. I'll send an earlier reminder in the new year about outstanding work, so it doesn't creep up on people the night before of the meeting.

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Maybe present: Olli, Patrick, Rob

All speakers: Mustaq, Olli, Patrick, Rob

Active on IRC: flackr, mustaq, Patrick_H_Lauke