Minutes from Pointer Events WG call 05 August 2020

Dear all,

minutes from today's call are at 
https://www.w3.org/2020/08/05-pointerevents-minutes.html and also copied 
below:

Pointer Events WG
05 Aug 2020
Agenda: 
https://lists.w3.org/Archives/Public/public-pointer-events/2020JulSep/0026.html

Attendees
Present
smaug, mustaq, Liviu
Regrets
Chair
Patrick H. Lauke
Scribe
Patrick H. Lauke

Contents

Topics

* touch-action and scrolling directional lock 
https://github.com/w3c/pointerevents/issues/303
* The behavior of `touch-action: none` on <iframe> is unclear 
https://github.com/w3c/pointerevents/issues/325
* Define event order relative to RAF? 
https://github.com/w3c/pointerevents/issues/9
* setPointerCapture should be disabled in sandboxed iframes by default 
https://github.com/w3c/pointerevents/issues/16
* Click event while a pointer event is captured 
https://github.com/w3c/pointerevents/issues/75

https://lists.w3.org/Archives/Public/public-pointer-events/2020JulSep/0020.html

* Changing the DOM hierarchy while handling a "pointerenter" event 
produces significantly different results across browsers 
https://github.com/w3c/pointerevents/issues/285

items from last call

smaug: Gary has some initial algorithm for that in the UI events issue

issue is two-fold: which events fire, and then interleave issue

sounds reasonable, but if you do DOM events mutation without actually 
moving pointer, the events may fire way later. for instance if using 
keyboard, you may get mouse or pointer events much later

you get the leave events when you move the pointer, not when they're 
removed from DOM

in gary's algo you keep the old event path alive until leave is dispatched

you end up possibly keeping quite a few elements alive until much later

mustaq: keeping deleted nodes dangling could be problematic

keeping all references alive JUST for the leave event

smaug: i like the concept, but it doesn't happen with mouseover and out 
either. maybe i should ping Apple on this, as that's closest to their 
concern, and they're usually most concerned with garbage collection etc

mustaq: so on PE we can't do anything until UI events issue is solved.

smaug: for the event firing part yes. for interleave, that's something 
we can clarify

patrick: from memory, we did leave it vague on purpose

mustaq: i think the reasoning was that an application would use EITHER 
mouse OR pointer, so the interleave and order was not going to be a 
real-world problem

smaug: we should reach out to graouts about it, as he should be able to 
comment on it

<mustaq> ...unless there is a mix of libraries who use both of them somehow.

<scribe> ACTION: Olli to reach out to graouts and gary

touch-action and scrolling directional lock 
https://github.com/w3c/pointerevents/issues/303
patrick: this is the issue navid commented on. seems that we'll go with 
option 1 from graouts. assigning to myself

<scribe> ACTION: patrick to review/add note to spec

The behavior of `touch-action: none` on <iframe> is unclear 
https://github.com/w3c/pointerevents/issues/325
mustaq: added a repro that works. repros in Chrome but not Firefox. if 
Olli can have a look at the codepen that would help

smaug: think i tested locally last time. touch action didn't affect the 
behavior
... so looks like all implementations work the same way

mustaq: so do we need a note ?

patrick: the fact that we are getting this question is good indicator 
that it's probably worht adding a note

<scribe> ACTION: patrick to review/add note about unintuitive behavior

Define event order relative to RAF? 
https://github.com/w3c/pointerevents/issues/9
patrick: doing some triage of oldest issues

to me this feels more like something more related to UI events in 
general, not PE

smaug: and it's not always clear what the best behavior is

currently implementations vary. Chrome is aligned with RAF, Firefox does 
something similar but in different way

patrick: we happy to close this as it's outside of scope for just PE?

smaug: yes as this likely affects mouse, touch etc as well

mustaq: should we open an issue against UI Events and *then* close this?

smaug: think navid filed something already...

in the spec there is a comment in the pointerraw sections about 
pointermove aligning to RAF (?). i think it's vague on purpose

patrick: closing this issue for now, as there's agreement it does feel 
like it goes beyond what PE can/should define. if anybody files an issue 
in UI events, leave a comment/xref

setPointerCapture should be disabled in sandboxed iframes by default 
https://github.com/w3c/pointerevents/issues/16
mustaq: i think what jacob rossi commented in june 2015 is right

one frame can't get another frame pointer easily

you can't capture easily. so i think this is fine (as is)

patrick: so ok to close with no change to spec, or do we need to note 
anything

mustaq: think iframes are independent with their numbering

olli: if ids are not just easy to guess, it won't be easy / a real-world 
problem

<scribe> ACTION: mustaq to look into the current state of play and 
comment on the bug

smaug: more an implementation issue that UAs should pick 
random/non-guessable ids

mustaq: [...] should the spec suggest that?

smaug: if you call capture API on all possible ids ... you might still 
manage

patrick: or would it be tricky to explicitly say it shouldn't allow from 
sandboxed iframes?

olli: it would be tedious/tricky to do

if the spec said the id must be random it might help a bit

spec already says that "new ids should not be predictable"

<smaug> https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid

just seems that implementations don't currently do it

Patrick: so we'll leave this for next time, mustaq to look over the 
issue again and summarise in github

Click event while a pointer event is captured 
https://github.com/w3c/pointerevents/issues/75
smaug: seems that Chrome's behaviour changed since then

mustaq: i think somebody closed issue, navid did some work in chrome, 
but then the issue got reopened

patrick: it seems navid worked on something in June 2017, then reopened. 
seems that was to iron out inconsistency with Edge at the time. nowadays 
though that should not be an issue anymore with Edge using Chromium

smaug: i don't quite understand chrome's behavior. firefox always fires 
click on the element where the up happened, but chrome behaves differently
... firefox always gets the click on the element that had the up

chrome gets click on grey if you start on green

mustaq: without capturing, it finds lowest common ancestor in the dom

patrick: and for safari, click always seems to go to grey

smaug: all browsers work differently

mustaq: every engine implements lowest common denominator differently. 
spec needs to be more explicit how it wants the behavior to be

smaug: trying to recall why firefox does it this way, seem to remember 
there was a special case. i did something just before chrome changed 
behaviour, to match it. then chrome changed

and i think navid's change broke some websites

ah no, firefox. i broke firefox

Liviu: so is grey click the expectation?

mustaq: depends how you interpret it (and how it interacts with the capture)

smaug: UI events can't know about capture, so behaviour is not fully 
spec'd there for this case

Liviu: wouldn't lowest common ancestor always be grey?

mustaq: depends how you interpret it once you capture

patrick: so we should define in PE as it's not appropriate/too specific 
for UI events

who here thinks they have a handle on this to propose something for PE

smaug: i need to first look at why firefox behaves the way it does

<scribe> ACTION: assigning issue to Olli to research further

Summary of Action Items
[NEW] ACTION: assigning issue to Olli to research further
[NEW] ACTION: mustaq to look into the current state of play and comment 
on the bug
[NEW] ACTION: Olli to reach out to graouts and gary
[NEW] ACTION: patrick to review/add note about unintuitive behavior
[NEW] ACTION: patrick to review/add note to spec


-- 
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, 5 August 2020 16:06:50 UTC