Intent to Ship: Clipboard: files support

[Joel Hockey]

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]

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]

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]

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]

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.

https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/clipboard/data_object_item.cc;l=117-120;drc=2ac64302ae161cd6b5e4b1254497bdf5fd6d3415

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

[Joel Hockey]

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]

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]

Thanks for the additional info! Adding cross-platform support for something that (kind of?) works on macOS sounds like a win.

[Darwin Huang]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPV4WLbKSDL%3D0JUyJ4RRiYHGYnpvaSav_Yvc-kembxyKircepQ%40mail.gmail.com.

[Joel Hockey]

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]

I have created a request for mozilla position https://github.com/mozilla/standards-positions/issues/484

[Joel Hockey]

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).

I have updated https://chromestatus.com/feature/5671807392677888 with statement:

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]

I have added explainer https://docs.google.com/document/d/1eHAs3R5UeWkAlOC0sJyULXRYUwWLPcFry_Wh9ThJ_CE/edit

[Joel Hockey]

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]

Code is now implemented behind chrome://flags#clipboard-filenames.

WPT tests now in:

https://github.com/web-platform-tests/wpt/tree/master/entries-api

https://github.com/web-platform-tests/wpt/blob/master/clipboard-apis/clipboard-file-manual.html

[Joel Hockey]

API owners, please review

[Chris Harrelson]

Hi Joel,

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ebb5ee9d-6b2e-43d3-9f9a-18b58e9d9eeen%40chromium.org.

[Joel Hockey]

Are there still questions?  This feature is implemented in M-90.

[Alex Russell]

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]

LGTM2

[TAMURA, Kent]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_VN6nVsi6QV8jVGaow1rAmRGNMGBYVBYMAYekC3vriug%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google