- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 5 Aug 2020 17:06:34 +0100
- To: public-pointer-events@w3.org
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