Spec readiness and compat

[evilpie]

I started working on an implementation of ClipboardItem and clipboard.write using that in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1619947

I don't think the current spec can be implemented without either reverse-engineering other browsers or just guessing.

• Especially ClipboardItem is missing descriptions of all its methods and properties. Some behavior can not just be inferred by name.
  • What is createDelayed? It's not implemented by Chrome
  • How to handle DOMString in ClipboardItemDataType. The rest of the spec only seems to handle Blob. (See also What does ClipboardItem.getType do #119)
    • Chrome only allows Blob not DOMString
  • Chrome only supports the types property. Safari seems to support presentationStyle as well.
  • I am especially concerned about the missing Promise support for ClipboardItemData in Chrome.
• clipboard.write
  • The spec doesn't really define which MIME types should be supported for write. Chrome only supports a handful.
  • Chrome has some restriction where the MIME type of the Blob and the corresponding DOMString MIME type in ClipboardItem must match

Sorry I can't easily test Safari, but looking at their IDL definition they also only implement a subset of this spec.

[annevk]

cc @rniwa @plehegar @foolip @RByers

[evilpie]

I am going to start landing the code for ClipboardItem in Firefox today. We are relatively close to the spec for the stuff we actually support, with the notable exception of Promise data in the ClipboardItem constructor. We currently don't support DOMString arguments yet, but I am already working on implementing that for performance reasons: https://bugzilla.mozilla.org/show_bug.cgi?id=1688279

I also added some new WPT that Chrome is probably going to fail: web-platform-tests/wpt#27311

[rniwa]

@whsieh

[dway123]

Hmm yeah, it is unfortunate that this isn't completely specified. My understanding is that the specification had quite a few properties (including presentationStyle, createDelayed, and Promise support for createDelayed) that were initially added to ensure this API would be flexible and future-proof for consensus. From there, each browser has generally implemented some subset so far, and hopes to implement the full feature-set in the future. Chrome indeed is currently missing a few of these properties (as you've discovered).

What is createDelayed? It's not implemented by Chrome

My understanding of createDelayed is that it is intended to be used for delayed rendering of clipboard formats, for example to send multiple large payloads (ex. 1 image, 1 text), and only copy/decode/generate them when they're first used (which may be expensive/slow), through underlying-platform features like Windows delayed rendering.

The spec doesn't really define which MIME types should be supported for write. Chrome only supports a handful.

This is quite unfortunate. The clipboard specification does specify Mandatory Data Types for DataTransfer and copy/cut/paste events, which interestingly does also only have a subset of these formats implemented in all browsers. I'd be supportive of modifying this section to also cover the Async Clipboard API, as blink now implements text/plain, text/html, and image/png, and I'm aware that webkit implements these same formats plus text/uri-list.

Thanks for pointing these out, and I agree that it'd be nice if the specification were more clear on these things.

cc @garykac

[foolip]

Thanks for adding some tests here, @evilpie!

Looking at https://wpt.fyi/results/clipboard-apis/async-navigator-clipboard-basics.https.html?run_id=5753596027076608&run_id=5764703215157248&run_id=5740072676622336 it looks like some subtests are failing in all browsers, notably "navigator.clipboard.write({string : DOMString}) succeeds". Are those tests correct per spec, or is the spec not specific enough?

Another ping for @garykac :)

[evilpie]

The test passes in Firefox when the correct prefs are set. I haven't tested Webkit.

Chrome is wrong, because they only implement support for Blob as ClipboardItemData in the ClipboardItem constructor and not DOMString.

[foolip]

I see, so the test is failing for different reasons. @garykac do you know if there's an open bug for what @evilpie is pointing out? I found https://bugs.chromium.org/p/chromium/issues/detail?id=487266 but don't think that's it.

[dway123]

I didn't find an open bug, but I did file a new one here to cover using DOMString in Chromium.

[snianu]

The spec doesn't really define which MIME types should be supported for write. Chrome only supports a handful.

We discussed this in the EditingTF meeting and there were few concerns raised in the meeting that we should probably address first before standardizing any formats in the Async clipboard APIs. Tagging @whsieh @dway123 @gked @BoCupp-Microsoft @johanneswilm to chime in if I missed anything.

1. Reading clipboard formats: Without proper sanitization of the formats, this could expose private data such as file paths, user data etc. Some formats are platform specific (e.g. WebArchive format on Mac) so do we also need to support those formats as well? If we want to standardize these formats then we need to define the sanitizers as well to strip out privacy related data and "insecure" content.
2. Writing clipboard formats: Same sanitization requirements as reading. Also impose restrictions on the number of formats that are written into the clipboard as some arbitrary sites could cause issues in the system clipboard which may not be recoverable(once the format is registered the entry cannot be removed via write APIs). Writing image formats also involves decoders so this exposes native decoders to arbitrary sites.

[dway123]

I'd support mentioning in the spec that we require sanitization to strip out privacy-sensitive information or content that could attack native decoders.

Mandatory data types defined in the spec currently are all platform-neutral. We could add support for platform-specific types, but this may be difficult for web developers to work with (they may require platform-dependent code, which was discouraged in previous discussions).