Intent to Ship: Selective Clipboard Format Read

6 views
Skip to first unread message

Shweta Bindal

unread,
4:02 AM (1 hour ago) 4:02 AM
to blink-dev, Rakesh Goulikar, Rohan Raja, ASHISH KUMAR
Contact emails
Explainer
Specification
Summary
Enhances the Asynchronous Clipboard API by deferring actual clipboard data retrieval from the OS until the web application calls getType(). Instead of eagerly fetching all available formats at read() time, the browser now returns ClipboardItem objects with available MIME types but without the underlying data, and reads from the OS clipboard only when getType() is invoked. const items = await navigator.clipboard.read(); // No data read yet const text = await items.getType('text/plain'); // Only 'text/plain' data read here This reduces CPU usage, improves the perceived responsiveness of the API call, and optimizes the browser's power consumption.

Blink component
Web Feature ID
Motivation
Currently, web applications can read clipboard content through the Async Clipboard API. However, the current implementation eagerly fetches all MIME types from the OS clipboard at read() time, regardless of which formats the application actually needs. This feature defers the actual data retrieval to getType() time, so the browser reads only the requested MIME types from the OS clipboard when they are needed, improving performance and reducing unnecessary data transfer.

Initial public proposal
TAG review
None requested because this behavior has achieved consensus in the Editing working group and matches what Safari already does

TAG review status
Not applicable

Goals for experimentation
NA

Risks


Interoperability and Compatibility
No information provided

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1279)

WebKit: Shipped/Shipping (https://github.com/WebKit/standards-positions/issues/537)

Web developers: Positive (https://github.com/WICG/proposals/issues/224) Webkit has already implemented this behavior

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?
No risks for WebView


Debuggability
No DevTools debugging support needed for this.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Yes
It is supported on all platforms because it is purely a browser-internal optimization that changes when existing OS clipboard APIs are called (deferring from read() time to getType() time), without requiring any new platform-specific clipboard capabilities or OS-level API changes.

Is this feature fully tested by web-platform-tests?
No
Added initial tests to WPT, but further coverage is currently blocked by missing test infrastructure. Created an issue for that (https://issues.chromium.org/issues/508091414)

Flag name on about://flags
DeferOsClipboardReadCallToGetType

Finch feature name
No information provided

Non-finch justification
As previously collected in UseCounters 5684 and 5685, telemetry tracking how often the clipboard changes between read and getType (or consecutive getType calls) shows an extremely low usage percentage (~0.0004). This data demonstrates that the risk of breaking existing workflows is negligible. Consequently, a Finch rollout is unnecessary.

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Tracking bug
Estimated milestones
Shipping on desktop
149
Shipping on Android
149
Shipping on WebView
149
Shipping on iOS
149


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).
N/A

Link to entry on the Chrome Platform Status
This intent message was generated by Chrome Platform Status.

Reply all
Reply to author
Forward
0 new messages