On Mon, Jul 29, 2024 at 5:04 PM Mustaq Ahmed <mus...@chromium.org> wrote:
> Re WebKit support: they have started implementing > <https://github.com/WebKit/standards-positions/issues/374#issuecomment-2253920961> > getCoalescedEvents(), > as per their update 2 days ago, yayy! Note that this PSA is about a corner > case of that API, more below. > > --- > > Re high use-counter: I agree with Rick that the use-counter is most likely > dominated by JS enumeration for cloning purposes, and I guess an http > archive analysis could confirm that. > > But more importantly, this PSA is not about the expected/common-sense > usage of getCoalescedEvents() to "read" the low-level trusted events that > are skipped by browser's RAF-aligned event dispatch. If the JS, for > whatever reasons, dumps into an untrusted PointerEvent an arbitrary list of > targets and offsetX/Y values ("arbitrary" in the sense that those values > were not returned by a trusted event's getCoalescedEvents list), > according to the spec the JS should be able to read back the values it > wrote. We are not aware of any real use-case that could be affected by > this change. > Thanks for the explanation! I'd be slightly more comfortable with this change if a quick HTTPArchive scan revealed that the usecounter is indeed mostly enumeration or otherwise unaffected. But I trust your expertise on this being very niche. > > > On Fri, Jul 26, 2024 at 12:37 PM Rick Byers <rby...@chromium.org> wrote: > >> >> >> On Fri, Jul 26, 2024 at 12:17 PM Yoav Weiss (@Shopify) < >> yoavwe...@chromium.org> wrote: >> >>> >>> >>> On Fri, Jul 26, 2024 at 5:04 PM Rick Byers <rby...@chromium.org> wrote: >>> >>>> >>>> >>>> On Fri, Jul 26, 2024 at 7:37 AM Yoav Weiss (@Shopify) < >>>> yoavwe...@chromium.org> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed <mus...@chromium.org> >>>>> wrote: >>>>> >>>>>> Contact emailsmus...@chromium.org >>>>>> >>>>>> Specification >>>>>> https://w3c.github.io/pointerevents/#populating-and-maintaining-the-coalesced-and-predicted-events-lists >>>>>> >>>>>> Summary >>>>>> >>>>>> For untrusted (i.e. JS constructed) PointerEvents, the events >>>>>> returned by PointerEvent.getCoalescedEvents() and >>>>>> PointerEvent.getPredictedEvents() will maintain their original targets >>>>>> and >>>>>> offsetX/Y coordinates, instead of behaving like trusted events where >>>>>> these >>>>>> fields are affected by the parent (container) event. >>>>>> >>>>>> >>>>>> Blink componentBlink>Input >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInput> >>>>>> >>>>>> TAG reviewNone >>>>>> >>>>>> TAG review statusNot applicable >>>>>> >>>>>> Risks >>>>>> >>>>>> >>>>>> Interoperability and Compatibility >>>>>> >>>>>> None >>>>>> >>>>> >>>>> Can you expand on that? Isn't something that developers can somehow >>>>> rely on? >>>>> >>>> >>>> Maybe in theory, but coalesced/predicted points are so niche, combined >>>> with constructed events, it seems really unlikely to me that anyone would >>>> notice. >>>> >>> >>> I could be missing something but the usecounters for coalesced >>> <https://chromestatus.com/metrics/feature/timeline/popularity/4859> don't >>> seem that niche (predicted >>> <https://chromestatus.com/metrics/feature/timeline/popularity/2971> is >>> indeed tiny). >>> >> >> Coalesced events are really useful only for art scenarios like drawing >> fine curves (https://rbyers.github.io/paint.html#cpoints for a demo). >> They report events at higher than the rendering frame rate, so AFAIK >> there's only downside (wasted work) to using them for the 99% case of >> scenarios where you want RAF-aligned events. >> >> When I saw this high use counter I was initially shocked but then >> remembered the common practice of some frameworks cloning all details of an >> input event into their own objects. We've struggled before with input event >> property UseCounters being essentially useless due to this pattern. But >> maybe it's worth a bit of investigation to confirm? >> >> This sounds like a tiny bug fix to me, arguably not even worthy of a PSA >>>> (but thanks for the extra diligence Mustaq!). Constructed events are >>>> supposed to just be however they were constructed. Of course we can always >>>> be surprised by even tiny-seeming bug-fixes... >>>> >>>> >>>>>> >>>>>> *Gecko*: Shipped/Shipping ( >>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1750994) >>>>>> >>>>>> *WebKit*: No signal >>>>>> >>>>> >>>>> Would this take us further away from WebKit interop? What's the >>>>> current state of their implementation? >>>>> >>>> >>>> getCoalescedPoints and getPredictedPoints aren't implemented by WebKit >>>> at all >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> *Web developers*: No signals >>>>>> >>>>>> *Other signals*: >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)?Yes >>>>>> >>>>>> Is this feature fully tested by web-platform-tests >>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>> ?Yes >>>>>> >>>>>> >>>>>> https://wpt.fyi/results/pointerevents/pointerevent_constructor.https.html?label=experimental&label=master&aligned >>>>>> >>>>>> >>>>>> Flag name on chrome://flagsNone >>>>>> >>>>>> Finch feature nameNone >>>>>> >>>>>> Non-finch justificationNone >>>>>> >>>>>> Requires code in //chrome?False >>>>>> >>>>>> Tracking bughttps://issues.chromium.org/353538500 >>>>>> >>>>>> Estimated milestones >>>>>> Shipping on desktop 128 >>>>>> Shipping on Android 128 >>>>>> Shipping on WebView 128 >>>>>> >>>>>> Anticipated spec changes >>>>>> >>>>>> Open questions about a feature may be a source of future web compat >>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>> issues in the project for the feature specification) whose resolution may >>>>>> introduce web compat/interop risk (e.g., changing to naming or structure >>>>>> of >>>>>> the API in a non-backward-compatible way). >>>>>> None >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> https://chromestatus.com/feature/5106728480538624?gate=5128518594461696 >>>>>> >>>>>> This intent message was generated by Chrome Platform Status >>>>>> <https://chromestatus.com/>. >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO6ogVhba4bQpZH9GE3Mh%2B04qqpvvorgXRZ_AJ-FQjwobQ%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO6ogVhba4bQpZH9GE3Mh%2B04qqpvvorgXRZ_AJ-FQjwobQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to blink-dev+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJyttfwuyqP-BtvOoUe5wEK5tkcgVRSz3%2B6RiaxBzK-sw%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJyttfwuyqP-BtvOoUe5wEK5tkcgVRSz3%2B6RiaxBzK-sw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2Buk-dDDnkV1Fuu2q%3DSV6kHg2ZLE41VoehxhraLos0bFQ%40mail.gmail.com.
