Feature detection for supported clipboard formats

[tomayac]

Migrated and adapted from #165 (comment):

I suggest we add some sort of feature-detection for custom and classic formats. This is actual nightmare-ish application code of mine that only makes sure copying works on three browsers (Firefox, Chrome, Safari): https://github.com/tomayac/SVGcode/blob/b29b27dadf2cf3c8aefb77e2c3db9feb0872d91d/src/js/clipboard.js#L64-L136

My suggestion would be to add a static function on ClipboardItem

ClipboardItem.supports('image/webp');
// `false`
ClipboardItem.supports('image/png');
// `true`
ClipboardItem.supports('web');
// `true`

Not sure how to express custom types here, as a ground for discussion I just went with "web". What do you think?

[annevk]

@snianu's comment needs addressing. (Also, once the processing model for the existing features is defined it might also reveal some ways that feature testing can work.)

[tomayac]

@snianu's comment needs addressing. (Also, once the processing model for the existing features is defined it might also reveal some ways that feature testing can work.)

Responded over in #165. I think there was a misunderstanding. Feature detection would mostly be needed to know what can be written.

[snianu]

Feature detection would mostly be needed to know what can be written.

Ah, that is indeed a problem for web authors. It would probably be beneficial to the web authors to also expose what mandatory types are supported by a browser? e.g. Chrome supports reading/writing SVG(image/svg+xml) using async APIs and Safari supports text/uri-list. Adding the agenda tag so we can discuss this in the EditingWG meeting. Thanks for reporting this issue!

[annevk]

So while you can feature detect by attempting to write a builtin type, that's not great as writing is an asynchronous operation. Therefore it would be better to have that information available synchronously upfront. (You also might want to write multiple types at the same time.)

[css-meeting-bot]

The Web Editing Working Group just discussed feature detection for clipboard.

The full IRC log of that discussion

<Travis> Topic: feature detection for clipboard
<Travis> github: https://github.com//issues/170
<Travis> snianu: Didn't have time to discuss internally; but authors should have an ability to get the available formats on the clipboard.
<Travis> .. not really sure if this is should be a new API or not.
<Travis> .. if the proposal sounds good to everyone then we don't have any objections.
<Travis> johanneswilm: Will MS be able to take this up next month?
<Travis> annevk: I was wondering what happens if you create a clipboard item for an unsupported format and try to write it?
<Travis> snianu: chromium throws today.
<Travis> annevk: Is that an OK single to know it isn't supported?
<Travis> whsieh: I think that's right... If the author tries to write and it throws an exception...
<Travis> .. Trying types until it doesn't throw is the current approach.
<Travis> Travis: maybe that's good enough, barring any other customer signal?
<Travis> johanneswilm: Scenario: say I have a format that takes a lot of time to prepare for a test (say WebP conversion before clipboard test)
<Travis> .. if that's the case, then I understand why authors would like to know before doing all that work.
<Travis> .. did I understand that correctly?
<Travis> Anupam: in chromium, that's the way it is.
<whsieh> those three are image/png, text/plain, and text/html I believe?
<Travis> .. there are some "manditory" formats that everyone supports.
<Travis> .. There are open questions about how some custom formats could become mandatory formats.
<Travis> .. suppose we could check for the prefix?
<Travis> johanneswilm: Scenario: I create a JS-based image format, then browsers change what they support. When I export to the clipboard I will need to keep a list of what browsers support and export as needed.
<Travis> .. I might first try one that is accepted, then try again if it throws.
<Travis> annevk: As I wrote... I think this does need addressing.
<Travis> .. if you wanted to write multiple at a time, you won't know which one wasn't supported.
<Travis> .. I think there is a real need for something like this.
<Travis> .. alternative is all browsers support the same formats.
<Travis> whsieh: I think there is compelling need if some browsers will support new formats that others won't... but in the current climate, this isn't very pressing.
<Travis> .. Do agree, we should investigate this.
<Travis> .. This is just about writing to the clipboard. The term "supports" is a little vague... would like to see a name more accurately reflecting that it's about writing.
<Travis> .. I will bring it up with my peers.
<Travis> johanneswilm: So we will want to hear from both Microsoft and Apple next meeting.
<Travis> Annevk: on the name, I think "supports" is probably OK. Seems like the most prominent thing and there is precident.
<Travis> .. I think it's OK from that perspective.

[snianu]

@BoCupp-Microsoft

[snianu]

Looks like this is a highly requested feature. Saw at least couple old issues(#67) in this repo requesting to expose this data to web authors.

[BoCupp-Microsoft]

In today's Editing WG meeting we resolved that ClipboardItem.supports should be added to the clipboard spec. I'll remove the Agenda+ label and expect this issue to be closed with a future PR.

[martinthomson]

A few comments on this change:

1. The fingerprinting risk was not identified in the privacy section.
2. "If type is in mandatory data types or optional data types, then return true." This reads as if you just concatenate the lists from each section, but I think that the second set needs to be filtered, with optional types that are not supported by the UA being removed.

[snianu]

The fingerprinting risk was not identified in the privacy section.

This API is just used for feature detection of a clipboard format which could be supported by multiple browsers so not sure if this has any fingerprinting issues. Could you please elaborate?

"If type is in mandatory data types or optional data types, then return true." This reads as if you just concatenate the lists from each section, but I think that the second set needs to be filtered, with optional types that are not supported by the UA being removed.

Note that the difference between the two list is the usage of the words MUST and MAY. In our previous conversations at EditingWG meetings, we agreed that we would add formats to the mandatory data types list only if it's supported by all three major browser vendors (FF, Webkit and Blink). But to document what MAY be supported by UAs, we added a separate list which is the optional data types.
The three formats listed in the optional data types are supported by at least two UAs(or planning to add support for it):
text/uri-list : Supported by Webkit and Blink has plans to support them as well.
image/svg+xml: Supported by Blink, but Webkit has plans to support them as well.
Web custom format: Supported by Blink, but Firefox has plans to support them as well in the future. Webkit can technically support them for same origin copy-paste as well.

[yisibl]

Should we case sensitive the web prefix? Are there any other APIs I can refer to?

The current implementation in Chrome returns the following:

ClipboardItem.supports('weB text/html') // → false
ClipboardItem.supports('web text/html') // → true
ClipboardItem.supports('web Text/html') // → true

[snianu]

@yisibl Please see #192 (comment) for more context on this change.

[yisibl]

@EdgarChen Which version of Firefox supports ClipboardItem.supports()?

Browser compatibility in MDN needs to be updated.

[saschanaz]

It's landed very recently and MDN update will be tracked by the dev-doc-needed keyword there. https://bugzilla.mozilla.org/show_bug.cgi?id=1858788