Web-Facing Change PSA: Coalesced/predicted events in untrusted PointerEvents will retain original targets

[Mustaq Ahmed]

Contact emails

mus...@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 component

Blink>Input

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1750994)

WebKit: No signal

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?

Yes

https://wpt.fyi/results/pointerevents/pointerevent_constructor.https.html?label=experimental&label=master&aligned

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://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.

[Yoav Weiss (@Shopify)]

On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed <mus...@chromium.org> wrote:

Contact emails

mus...@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 component

Blink>Input

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

None

Can you expand on that? Isn't something that developers can somehow rely on? 

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?

 

--
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+...@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.

[Rick Byers]

On Fri, Jul 26, 2024 at 7:37 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed <mus...@chromium.org> wrote:

Contact emails

mus...@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 component

Blink>Input

TAG review

None

TAG review status

Not 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. 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

 

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.

[Yoav Weiss (@Shopify)]

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) <yoav...@chromium.org> wrote:

On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed <mus...@chromium.org> wrote:

Contact emails

mus...@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 component

Blink>Input

TAG review

None

TAG review status

Not 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 don't seem that niche (predicted is indeed tiny).

[Rick Byers]

On Fri, Jul 26, 2024 at 12:17 PM Yoav Weiss (@Shopify) <yoav...@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) <yoav...@chromium.org> wrote:

On Wed, Jul 17, 2024 at 4:25 PM Mustaq Ahmed <mus...@chromium.org> wrote:

Contact emails

mus...@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 component

Blink>Input

TAG review

None

TAG review status

Not 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 don't seem that niche (predicted 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?

[Mustaq Ahmed]

Re WebKit support: they have started implementing 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.

[Yoav Weiss (@Shopify)]

On Mon, Jul 29, 2024 at 5:04 PM Mustaq Ahmed <mus...@chromium.org> wrote:

Re WebKit support: they have started implementing 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.