Minutes from Pointer Events WG call 2 February 2022

Dear all,

the minutes from today's meeting are at 
https://www.w3.org/2022/02/02-pointerevents-minutes.html and copied below:

02 February 2022


flackr, mustaq, Patrick_H_Lauke, smaug

Chair:  Patrick H. Lauke
Scribe:  Patrick H. Lauke, Patrick_H_Lauke

* Should triggering the contextmenu with the mouse cause a 
pointercancel? https://github.com/w3c/pointerevents/issues/408

# Should triggering the contextmenu with the mouse cause a 
pointercancel? https://github.com/w3c/pointerevents/issues/408

[discussion on how this might be platform specific - linux behaving 
differently from windows]

Rob: it has always been an issue that if mouse/pointer leaves your page 
that you don't know if the button is still active

Olli: what should happen with pointercapture

Olli: on linux, if i have capture checkbox enabled, and right click, i 
don't get any capture events

Olli: this in chrome. in firefox, i do see contextmenu and then 


Patrick: in Safari/macOS, with capture checkbox checked, i get 
pointerdown, gotpointercapture,contextmenu, and that's it

Patrick: can we naively say "when contextmenu is fired, fire 
pointercancel (and then whatever happens with capture is implicit with 
the fact that it's cancelled, i.e. fire lostpointercapture)"

Rob: maybe be more generic, not just contextmenu. whenever the focus of 
the pointer is lost, cancel the pointer (?)

[discussion on what happens switching between windows and maintaining 

<mustaq> Canceling intuitively means a "hard"ish break nin event stream


Rob: if i get my context menu, i don't expect my drag to continue

Olli: if you press Esc you can continue your mouse event stream

Rob: one way of viewing this is that the pointer is cancelled, and then 
it reappears later

Mustaq: what's the difference, conceptually, between getting pointerout 
and pointercancel

Rob: ... we should ensure that the stream of events makes sense. they're 
not going to get events when contextmenu comes up, but event stream 
should not suggest that pointer is still down

Olli: but the pointer MAY be still down, if you close contextmenu with esc

Patrick: https://www.youtube.com/shorts/oggIAZ9uHug

Patrick: slightly related touch events / iOS/Safari bug where even after 
opening context menu the touch events/scroll still fires behind the 
context menu

[discussion on whether firing pointerout rather than pointercancel would 
be sufficient/more universally applicable]

Rob: what's good about pointercancel though is that is sends a clear 
signal to developers that are listening to events

Patrick: the nice thing with pointercancel is that it then does the 
capture release for free 

Rob: i like the implicit release because it handles all the things for 
this use case

Mustaq: we want to guarantee that for every "got" there's a "lost"

Rob: if you want to make dev lives easier, you probably want to send a 
promise, rather than making them wait for another event

Rob: we should at least be sending an out event...

<flackr> https://rbyers.github.io/eventTest.html without capture shows 
out events and no more information after the cursor leaves the window

[discussion on other scenarios other than contextmenu that may interrupt 
event stream - alert() boxes for instance. should conceptually fire just 
before the context menu/alert/etc fires it. the event won't be actually 
received by the page until the event loop runs again, but at least the 
application will then be able to get itself in the correct state rather 
than still having a hanging "i've still got the capture / the pointer is

still down as i didn't see an up/etc" assumption]

Rob: we have wording in pointercancel that suggest it's about hardware 
events that stop the stream. we could expand that to cover other scenarios

Patrick: happy to make an initial strawman PR that just adds more 
wording to the pointercancel definition to also cover contextmenu etc

Olli: would this then also cover the other issue "Lost pointer issue - 
spec or browser bug?" https://github.com/w3c/pointerevents/issues/407

Patrick: i think so, as these are related

Olli: will need to see if we can make a test for this

Rob: I think we have some tests using webdriver (using touch, not 
exactly the same, but leads me to believe we can use contextmenus in WPT 

Patrick: do we still allow manual tests for WPT, been ages since i looked

Rob: yes, that's always an option

ACTION: Patrick to expand pointercancel definition to also mention 
contextmenu etc as examples, not just suggesting it's hardware events 
that may stop stream

[discussion on some existing WPT tests relating to right-click, 
contextmenu key on keyboard, and if they could be used as basis]

Patrick: we'll look at tests next time. meanwhile thank you all, see you 
in two weeks' time

Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Wednesday, 2 February 2022 17:28:33 UTC