Intent to Ship: Remove PointerEvent.getCoalescedEvents() from insecure contexts

Contact emails

[email protected]

Explainer

None

Specification

https://w3c.github.io/pointerevents/#pointerevent-interface

Summary

The Pointer Events Working Group made PointerEvent.getCoalescedEvents() restricted to secure contexts 4+ years ago, which removed the API from insecure contexts. Chrome originally shipped the old behavior and didn't follow the spec change immediately because of compat concerns. We are now removing it from insecure contexts because Chrome usage in insecure contexts turned out to be very low.

Blink component

Blink>Input

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

Interop: This will improves Interop, making Chrome fully match Firefox (and the spec). Compat: There is a bit of risk because the usage is non-zero (~0.0004% as of 2024-07-16). This usage stat is expected to include non-breaking JS enumerations. https://chromestatus.com/metrics/feature/timeline/popularity/4598

Gecko: Shipped/Shipping

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?label=master&label=experimental&aligned&q=pointerevents%2Fpointerevent_constructor

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/40928769

Estimated milestones

Shipping on desktop

129

Shipping on Android

129

Shipping on WebView

129

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/4941651093749760?gate=5095189648244736

This intent message was generated by Chrome Platform Status.

On 7/17/24 10:18 AM, Mustaq Ahmed wrote:

> Can you ask for WebKit's position? Or maye there's at least a pointer to working group discussions they participated in?

- Safari doesn't yet support PointerEvent.getCoalescedEvents(), so we can't ask for their position on secure/non-secure context differences:

https://developer.mozilla.org/en-US/docs/Web/API/PointerEvent/getCoalescedEvents#browser_compatibility

That's OK - we ask for positions from them all the time for things they don't support.

- Here is a PEWG discussion started by @gsnedders from WebKit (I couldn't find any other related discussion Safari participated in):

https://github.com/w3c/pointerevents/issues/215

To my knowledge, that was posted a few years before Sam started working at Apple.

Could you also request the Enterprise bit?

In the meantime - I'd love to know more about `[SecureContext=flag]` not working - that capability was introduced to make these types of roll outs safer, IIRC. In the past I've had to write postmortems because I thought usage was low enough, but the breakage was in enterprise environments that disable telemetry... and didn't have a finch flag to quickly revert. :(

(I'm also not trying to send you on an impossible side-quest, but won't be sad if someone is nerd sniped into fixing what feels like a regression).