Looking forward to this, it seems a good optimization no web developer API change. How long has this been shipped in Safari?
On Thu, May 14, 2026 at 1:03 AM 'Shweta Bindal' via blink-dev < [email protected]> wrote: > *Contact emails* > [email protected], [email protected], > [email protected] > > *Explainer* > > https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ClipboardAPI/SelectiveClipboardFormatRead/explainer.md > > *Specification* > https://github.com/w3c/clipboard-apis/pull/248 > > *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* > Blink>DataTransfer > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EDataTransfer%22> > > *Web Feature ID* > async-clipboard <https://webstatus.dev/features/async-clipboard> > > *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* > https://github.com/WICG/proposals/issues/224 > > *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* > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > *?* > 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* > https://issues.chromium.org/issues/435051711 > > *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* > https://chromestatus.com/feature/5203433409871872?gate=6255790323269632 > > 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 [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/JH0P153MB1062E1AE43E6CECD8926ED17D1072%40JH0P153MB1062.APCP153.PROD.OUTLOOK.COM > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/JH0P153MB1062E1AE43E6CECD8926ED17D1072%40JH0P153MB1062.APCP153.PROD.OUTLOOK.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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK-EfXmLVE1ryi-bsEp9Wzn0_%3D3hq7QXpjY5jXzKrbAuO7UZVA%40mail.gmail.com.
