<scribe> Scribe: Patrick H. Lauke
<scribe> ScribeNick: Patrick_H_Lauke
<smaug> will be there in a moment
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
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
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
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
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
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
rsagent, generate minutes
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: smaug mustaq Liviu Found Scribe: Patrick H. Lauke Found ScribeNick: Patrick_H_Lauke Agenda: https://lists.w3.org/Archives/Public/public-pointer-events/2020JulSep/0026.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: assigning issue mustaq olli patrick WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]