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.
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/CAB0cuO70w5qRp1Ce9GN-rw6HDSU39jngmNniap30_uL3pX%3DjbQ%40mail.gmail.com.
