Intent to Ship: Clipboard: files support

203 views
Skip to first unread message

Joel Hockey

unread,
Feb 10, 2021, 7:32:48 PMFeb 10
to blink-dev

Contact emails

joelh...@chromium.org

Explainer

None

Specification

https://w3c.github.io/clipboard-apis/#clipboard-event-api

API spec

Yes

Summary

Support files in clipboard. Files can currently be used with drag-and-drop, but not clipboard (cut, copy, paste). This proposes to expose files on the clipboard to renderers using a similar approach to drag-and drop. async function onPaste(e) { let file = e.clipboardData.files[0]; let contents = await file.text(); } This feature is already supported in safari for mac.



Blink component

Blink>DataTransfer

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

None



Gecko: No signal

WebKit: No signal

Web developers: No signals


Is this feature fully tested by web-platform-tests?

No

Tracking bug

http://crbug.com/1175483

Launch bug

http://crbug.com/1174897

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5671807392677888

This intent message was generated by Chrome Platform Status.

Marijn Kruisselbrink

unread,
Feb 10, 2021, 7:39:44 PMFeb 10
to Joel Hockey, blink-dev
Can you clarify a bit more what exactly this intent covers? Is this purely about adding read support for files on the clipboard, or does this also cover writing files to the clipboard?

Also this only covers the (legacy) event based clipboard API, not the newer async clipboard API I believe? Are there plans/thoughts about how this functionality could work with the async clipboard API?

On Wed, Feb 10, 2021 at 4:32 PM Joel Hockey <joelh...@chromium.org> wrote:

Contact emails

joelh...@chromium.org

Explainer

None

Specification

https://w3c.github.io/clipboard-apis/#clipboard-event-api

API spec

Yes

Summary

Support files in clipboard. Files can currently be used with drag-and-drop, but not clipboard (cut, copy, paste). This proposes to expose files on the clipboard to renderers using a similar approach to drag-and drop. async function onPaste(e) { let file = e.clipboardData.files[0]; let contents = await file.text(); } This feature is already supported in safari for mac.



Blink component

Blink>DataTransfer

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

None



Gecko: No signal

WebKit: No signal
Since Safari actually supports this should probably be "Shipped/Shipping"?

Web developers: No signals


Is this feature fully tested by web-platform-tests?

No 


Tracking bug

http://crbug.com/1175483

Launch bug

http://crbug.com/1174897

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5671807392677888

This intent message was generated by Chrome Platform Status.

--
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/CAJJNyZaTGMZAfXmoge0CCOFBsoxObZBjGTjt6HXkft6cLtgZyQ%40mail.gmail.com.

Joel Hockey

unread,
Feb 10, 2021, 7:55:42 PMFeb 10
to Marijn Kruisselbrink, blink-dev
This feature is read-only from clipboard (renderer cannot write filenames to clipboard), but for filenames that are read from the clipboard, a renderer can read/write those files (same as how drag and drop works).

This feature is only for the DataTransfer API.  The clipboard async API does not currently include files.  That work is tracked in crbug.com/1099775.  I expect there is still a lot to consider about the permission model and user activation for the async API.

Mike Taylor

unread,
Feb 10, 2021, 8:47:29 PMFeb 10
to Joel Hockey, blink-dev
Hi Joel,

On 2/10/21 6:32 PM, Joel Hockey wrote:
> Support files in clipboard. Files can currently be used with
> drag-and-drop, but not clipboard (cut, copy, paste). This proposes to
> expose files on the clipboard to renderers using a similar approach to
> drag-and drop. async function onPaste(e) { let file =
> e.clipboardData.files[0]; let contents = await file.text(); } This
> feature is already supported in safari for mac.

I was playing around with
<https://evercoder.github.io/clipboard-inspector/> (AFAICT, it's not
using the async APIs) and learned that pasting an image file (but no
more than 1) works today in Chrome 88 and Firefox 87. Multiple image
files seems to work in Safari 14.

PDF also seems to sort of work, at least in clipboardData.items as an image.

Which (non-image) content types does this intent aim to add support for?

(It's also possible I'm confused, I don't know much about clipboard APIs)

> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?
>
> No

Is there a plan to add tests for this to
<https://github.com/web-platform-tests/wpt/tree/master/clipboard-apis>?
(even just manual ones would be nice)

thanks,
Mike

Joel Hockey

unread,
Feb 10, 2021, 9:43:54 PMFeb 10
to Mike Taylor, blink-dev
I just tested that, and the image file paste only worked for me on mac (not windows or linux).

I can see that the clipboard does have some special case handling to represent an image as a DataTransfer File, but this relies on the OS pasting the file into the clipboard as both a file path, and pasting the file contents as image type.


This adds support for all file types (text files, binary files, all).

Joel Hockey

unread,
Feb 10, 2021, 9:57:49 PMFeb 10
to Mike Taylor, blink-dev, Darwin Huang
I verified on other OSes (not mac) if you copy an image (not the file but the image - e.g. open the image in chrome and right-click > copy image) then paste that image, it shows up as DataTransfer File.

Mike, sorry I didn't respond about the tests.  I'll follow up with @huangdarwin to see what tests could be possible.

Yoav Weiss

unread,
Feb 11, 2021, 8:32:17 AMFeb 11
to Joel Hockey, blink-dev
On Thu, Feb 11, 2021 at 1:32 AM Joel Hockey <joelh...@chromium.org> wrote:

Contact emails

joelh...@chromium.org

Explainer

None

An explainer would help to clarify what it is you're intending to ship here.
 


Specification

https://w3c.github.io/clipboard-apis/#clipboard-event-api

API spec

Yes

Summary

Support files in clipboard. Files can currently be used with drag-and-drop, but not clipboard (cut, copy, paste). This proposes to expose files on the clipboard to renderers using a similar approach to drag-and drop. async function onPaste(e) { let file = e.clipboardData.files[0]; let contents = await file.text(); } This feature is already supported in safari for mac.



Blink component

Blink>DataTransfer

TAG review

None

TAG review status

Not applicable

Risks



Interoperability and Compatibility

None



Gecko: No signal

Can you ask for signals? https://bit.ly/blink-signals
 

WebKit: No signal

Didn't you say up top that it is shipped already?


Web developers: No signals


Is this feature fully tested by web-platform-tests?

No

As Mike suggested, testing would be good.
 


Tracking bug

http://crbug.com/1175483

Launch bug

http://crbug.com/1174897

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5671807392677888

This intent message was generated by Chrome Platform Status.

--

Mike Taylor

unread,
Feb 11, 2021, 10:19:05 AMFeb 11
to Joel Hockey, blink-dev, Darwin Huang
Thanks for the additional info! Adding cross-platform support for something that (kind of?) works on macOS sounds like a win.

Darwin Huang

unread,
Feb 11, 2021, 11:51:22 AMFeb 11
to Mike Taylor, Joel Hockey, blink-dev
Adding tests to web-platform-tests (WPT) would be nice, so that we can share these tests with other browser vendors.

We can't really add automated WPT for this, because we're only implementing file read (and not file write), as I understand it, so there would be no way to place a file on the clipboard in an automated WPT.

We certainly can make a manual test though, where the user must (1) download a file, (2) copy it in a OS file manager, (3) paste it on the test site. From there, the test could compare the actual pasted with the expected file info.

For reference: Here's an example of a manual clipboard test, and here's an example of a manual (drag-and-drop) test with File interaction, and here's the clipboard WPT directory.
--
- Darwin Huang

Joshua Bell

unread,
Feb 11, 2021, 1:11:40 PMFeb 11
to Darwin Huang, Mike Taylor, Joel Hockey, blink-dev
On Thu, Feb 11, 2021 at 8:51 AM Darwin Huang <huang...@chromium.org> wrote:
Adding tests to web-platform-tests (WPT) would be nice, so that we can share these tests with other browser vendors.

We can't really add automated WPT for this, because we're only implementing file read (and not file write), as I understand it, so there would be no way to place a file on the clipboard in an automated WPT.

We certainly can make a manual test though, where the user must (1) download a file, (2) copy it in a OS file manager, (3) paste it on the test site. From there, the test could compare the actual pasted with the expected file info.

For reference: Here's an example of a manual clipboard test, and here's an example of a manual (drag-and-drop) test with File interaction, and here's the clipboard WPT directory.

And there are file drag/drop manual tests in WPT here: https://github.com/web-platform-tests/wpt/tree/master/entries-api that require the user to download the test's resource files, as Darwin suggests.
 
--
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.

Joel Hockey

unread,
Feb 11, 2021, 5:33:22 PMFeb 11
to Joshua Bell, Darwin Huang, Mike Taylor, blink-dev
Yoav,

Sorry, this is my first time using chromestatus.com or developing a feature with an 'Intent to Ship', so I'm not so familiar with the process or tools.

I haven't provided an explainer since this is an existing feature implementation and the summary explains the change.  I've updated the summary to cover the query from Marijn and clarify that renderers will have access to read file paths from the clipboard, but not write paths to the clipboard. For file paths on the clipboard, renderers can read and modify the files. Is there any particular question that you have about the feature?

I've updated https://chromestatus.com/feature/5671807392677888 with the webkit status and a link to their blog post from 2018.

I read the link you gave about checking signals with mozilla, and I'm a bit confused.  The clipboard API is not a new spec so it doesn't really feel like I should be asking for a standards position from them. If someone knows this process better, please let me know if I should file a standards position request.

I see that they do have some open bugs for this feature, the most relevant being https://bugzilla.mozilla.org/show_bug.cgi?id=1087675.  I've added that link.

All,
I'll investigate adding some manual tests.


Joel Hockey

unread,
Feb 11, 2021, 7:21:50 PMFeb 11
to Joshua Bell, Darwin Huang, Mike Taylor, blink-dev
I have created a request for mozilla position https://github.com/mozilla/standards-positions/issues/484

Joel Hockey

unread,
Feb 11, 2021, 10:09:27 PMFeb 11
to Joshua Bell, Darwin Huang, Mike Taylor, blink-dev
I incorrectly said before:

"for filenames that are read from the clipboard, a renderer can read/write those files (same as how drag and drop works)"

This statement is correct that the access is the same as drag-and-drop, but is incorrect to say that it is read/write.  The access to files is read-only (with exception for things like ChromeOS FilesApp which have already been granted write-access to the entire isolated filesystem).

Renderers will have access to read file paths from the clipboard, but not write paths to the clipboard. For file paths on the clipboard, renderers will have read-only access.

Joel Hockey

unread,
Feb 11, 2021, 10:42:03 PMFeb 11
to Joshua Bell, Darwin Huang, Mike Taylor, blink-dev

Joel Hockey

unread,
Feb 14, 2021, 10:48:50 PMFeb 14
to Joshua Bell, Darwin Huang, Mike Taylor, blink-dev
Joshua, thanks for the link to the entries-api tests.  I was able to make all of then event-api tests work for both drag-and-drop, and copy-paste, with a small change to listen for the 'paste' event in addition to the 'drop' event.  That is exactly what I hoped / expected.

Clipboard files test also added in crrev.com/c/2695188


Joel Hockey

unread,
Feb 24, 2021, 11:05:12 PMFeb 24
to Joshua Bell, Darwin Huang, Mike Taylor, blink-dev

Joel Hockey

unread,
Feb 26, 2021, 5:28:19 PMFeb 26
to blink-dev, joelh...@chromium.org, huang...@chromium.org, Mike Taylor, blink-dev, Joshua Bell
API owners, please review

Chris Harrelson

unread,
Feb 26, 2021, 5:29:13 PMFeb 26
to Joel Hockey, Alex Russell, blink-dev, joelh...@chromium.org, huang...@chromium.org, Mike Taylor, Joshua Bell
Hi Joel,

Sorry for the slow reply. +Alex Russell will follow up soon with some more questions.

Joel Hockey

unread,
Mar 3, 2021, 4:27:33 PMMar 3
to Chris Harrelson, Joel Hockey, Alex Russell, blink-dev, huang...@chromium.org, Mike Taylor, Joshua Bell
Are there still questions?  This feature is implemented in M-90.

Alex Russell

unread,
Mar 4, 2021, 3:57:42 PMMar 4
to Joel Hockey, Chris Harrelson, Joel Hockey, blink-dev, huang...@chromium.org, Mike Taylor, Joshua Bell, Alice Boxhall
Hey all,

Joel and I caught up and clarified a few things for me that I'd missed from the thread:
  • This is existing API in the spec, and there's no new surface area being exposed vs. previous reviews of clipboard features. As as result, I support not filing for TAG review here (+aboxhall@ on that in case my intuition is wrong)
  • Safari has already shipped this behavior which is now captured in the chromestatus issue
  • Google's security and privacy teams have signed off
All of that in mind, LGTM1

Chris Harrelson

unread,
Mar 9, 2021, 7:11:44 PMMar 9
to Alex Russell, Joel Hockey, Joel Hockey, blink-dev, huang...@chromium.org, Mike Taylor, Joshua Bell, Alice Boxhall
LGTM2

TAMURA, Kent

unread,
Mar 9, 2021, 8:18:03 PMMar 9
to Joel Hockey, blink-dev, Joel Hockey
LGTM3




--
TAMURA Kent
Software Engineer, Google


Reply all
Reply to author
Forward
0 new messages