Intent to Implement: Async Clipboard read/write with image support
huang...@chromium.org
Contact emails
huang...@chromium.org, gar...@chromium.org, pwn...@chromium.org
Explainer
Background explainer (for original Async Clipboard API) Explainer link
Read/Write Image Explainer) (earlier discussion/background)
Spec
w3c.github.io/clipboard-apis/#async-clipboard-api
Tag review
None, but the tag review will be completed before our Intent to Ship. (previous tag review for text-only)
Summary
Add programmatic copy/paste support of images to/from the Async Clipboard API. This would allow scripts to write images (ex. copy) to the OS clipboard, or read (ex. paste) images already on the OS clipboard.
To avoid security implications, originating from image decoders with remote code execution (RCE) security vulnerabilities (ex. Firefox and Webkit (iOS/Safari/etc)) on other native apps (especially non-updated native apps), Chrome will re-encode images and drop all attached metadata, just as the existing clipboard does when copy/pasting images. The same re-encoding settings will be used for parity.
As image reencoding is expensive and slow, it would cause unacceptable jank if done on the main thread, especially for large images. Therefore, images will be re-encoded on a background thread.
The Async Clipboard API’s read() and write() functions will also be reimplemented and extended to include image support, as it previously only supported plain text, and standards have moved since then to no longer approve of the use of DataTransfer, and to opt for Blobs instead.
Motivation
As the most starred bug for Chromium (crbug.com/150835), addition of programmatic image clipboard support has high demand. Without it, web developers often use loopholes, like writing text/plain and then parsing the text/plain payload as an image (crbug.com/150835#c67), or creating selections, sometimes of invisible HTML image elements, and running document.execcommand(‘copy’) (owaisafaq.com/blog/demos/copier/). These methods are complicated, synchronous (may introduce jank), and ultimately a longstanding source of complaints that have led to the popularity of the aforementioned bug.
Risks
Interoperability and Compatibility
This feature is part of the Async Clipboard API discussion, which has received positive feedback from Firefox, Edge, and Safari, as well as web developers. For this specific feature, discussion is generally positive, and browser vendors are actively engaged in spec discussions (www.w3.org/2018/10/23-WebPlat-minutes.html#item02)
Edge: Actively engaged in spec discussions
Firefox: Actively engaged in spec discussions
Safari: Actively engaged in spec discussions
Web / Framework developers: Very positive support from websites with image support needs, such as Figma, as evidenced by the bug having more than >1800 stars crbug.com/150835.
Ergonomics
This feature will frequently be used in tandem with the Blob API, FileReader API, and Fetch API. As all these APIs are fairly asynchronous and performant, and this API runs on a background thread and returns asynchronously, this should not negatively impact performance.
Activation
This library should be fairly easy to use, especially when compared to existing methods using document.execcommand(‘copy’);
Debuggability
Dedicated debugging support on DevTools is not required for this change.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Tests:
Link to entry on the feature dashboard
https://www.chromestatus.com/features/5074658793619456
Requesting approval to ship?
No
Daniel Bratell
--
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/d6e2d8af-45ef-4761-aa2e-42ee4e117b2b%40chromium.org.
huang...@chromium.org
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d6e2d8af-45ef-4761-aa2e-42ee4e117b2b%40chromium.org.
gl...@microsoft.com
To avoid security implications, originating from image decoders with remote code execution (RCE) security vulnerabilities (ex. Firefox and Webkit (iOS/Safari/etc)) on other native apps (especially non-updated native apps), Chrome will re-encode images and drop all attached metadata, just as the existing clipboard does when copy/pasting images. The same re-encoding settings will be used for parity.'
