Contact emails [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[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.
