Clipboard API

[AshleyScirra]

Description

Modern clipboard APIs have been around for a while, so we don't need to rely on things like document.execCommand('copy') any more. However support is still patchy and inconsistent across browsers, meaning fallbacks are still sometimes required.

Rationale

Using the clipboard is a very common task for web developers - e.g. this StackOverflow question "How do I copy to the clipboard in JavaScript?" has over 4000 votes.

However reading from the clipboard is still not supported in Firefox (readText() is only supported in extensions, not web content). Browsers have different rules about when access is allowed (see #142). Support for binary formats and certain MIME types appears to be mixed (e.g. is HTML allowed? AVIF images? SVG? is metadata preserved? etc), and there's newer support for "Web Custom Formats". Overall it's all a mixed bag. It would be good if this was a robustly interoperable part of the web platform.

Specification

https://www.w3.org/TR/clipboard-apis/

Tests

https://wpt.fyi/results/clipboard-apis

[jgraham]

Could we split out the async clipboard APIs and other clipboard APIs into different proposals? Making a proposal for async clipbaord was part of the outcome of the 2022 editing investigation (web-platform-tests/interop-2022-editing#7), so I think that likely has a greater level of support compared to changes to the non-async clipbaord API.

If you want to propose both, I'm happy to do the work to file a seperate proposal for async clipboard. Otherwise we could modify this proposal to just drop the non-async parts.

[AshleyScirra]

In this proposal I was referring to the modern clipboard API (navigator.clipboard), which AFAIK is already all async. What non-async clipboard APIs are there? If you mean things like document.execCommand('copy'), I'm not actually bothered about that - navigator.clipboard is clearly a better replacement and that is what I was focused on improving, because the interop isn't quite there yet.

[jgraham]

Some observations on the tests:

• https://wpt.fyi/results/clipboard-apis/permissions?label=experimental&label=master&aligned - We believe that these tests don't match the permissions model that Gecko and WebKit are adopting, and require an update to correctly test all implementations.
• https://wpt.fyi/results/clipboard-apis/async-write-svg-read-svg.https.html?label=experimental&label=master&aligned https://wpt.fyi/results/clipboard-apis/async-svg-script-removal.https.html?label=experimental&label=master&aligned https://wpt.fyi/results/clipboard-apis/async-custom-formats-write-read.tentative.https.html?label=experimental&label=master&aligned - SVG and custom types we believe are lower priority than the other aspects of this feature and, absent a compelling reason that assessment is wrong, we'd prefer they are removed from the proposal.

[foolip]

@jgraham to make it explicit, there's no splitting required here, right?

[svoisen]

SVG and custom types we believe are lower priority than the other aspects of this feature and, absent a compelling reason that assessment is wrong, we'd prefer they are removed from the proposal.

This feels like it deserves its own proposal and I'd be happy to submit one. But absent that, I will chime in here with a note of support: We (Adobe) are very keen on seeing support for web custom formats across browsers. This is an important API that would greatly improve copy-paste workflows for any web application that makes use of custom formats (drawing tools, word processors, photo editors, etc.) Though native SVG support would also be nice, it seems to be sanitized to the point of uselessness (at least in Chromium), whereas web custom formats offers a suitable workaround to this issue.

[whsieh]

In WebKit (and Gecko, AFAIK) many of these web platform tests in wpt/clipboard-apis are failing due to the fact that clipboard APIs in our engine don't rely on the Permissions API at all; instead, programmatic clipboard access is gated on user activation requirements, which these tests don't seem to trigger (at least, most of these tests).

Additionally, the permissions API is unimplemented in WebDriver in WebKit; even when running the tests in clipboard-apis after removing the engine-level user activation requirements to read/write clipboard data in the WebKit, I'm observing the following errors:

  ▶ Unexpected subtest result in /clipboard-apis/text-write-read/async-writeText-readText.https.html:
  │ FAIL [expected PASS] Verify write and read clipboard given text: Clipboard write text -> read text test
  │   → promise_test: Unhandled rejection with value: "error: Action set_permission not implemented"
  │ FAIL [expected PASS] Verify write and read clipboard given text: non-Latin1 text encoding test \u30c7\u30fc\u30bf
  │   → promise_test: Unhandled rejection with value: "error: Action set_permission not implemented"

So it appears that in order for these tests to pass in WebKit, we would need to:

• Implement set_permission in test_driver / test_driver_internal.
• Honor set_permission({name: 'clipboard-{read|write}'}, 'granted') by lifting restrictions on programmatic clipboard access.

[jgraham]

To be clear, we consider the priority of https://wpt.fyi/results/clipboard-apis/async-write-svg-read-svg.https.html?label=experimental&label=master&aligned https://wpt.fyi/results/clipboard-apis/async-svg-script-removal.https.html?label=experimental&label=master&aligned https://wpt.fyi/results/clipboard-apis/async-custom-formats-write-read.tentative.https.html?label=experimental&label=master&aligned to be different in scope/priority to the other work in this proposal, and we'd like to see it split into a different proposal.

[AshleyScirra]

For the record, I'm happy for the interop team to do whatever they wish with this proposal, including splitting it or addressing any subset of the proposal at their discretion.

[chrishtr]

@i've created issue #241 for SVG and custom types, per our discussion at the interop meeting last week.

[gsnedders]

From that WPT issue:

Currently a lot of the Clipboard API tests rely on the clipboard-read and clipboard-write permissions. These were removed in w3c/clipboard-apis#132 and pending-removal in w3c/clipboard-apis#164.

So there's probably quite a lot of test work involved here, if we have agreement about what the permission or gesture or whatever should be?

[foolip]

There's some discussion about the user gesture requirements in w3c/clipboard-apis#182.

[foolip]

In the MDN short survey on APIs & JavaScript, "Clipboard API (navigator.clipboard)" was selected by ~21% of survey takers, putting it in the top third of options. (There is some uncertainty as with any survey data.)

[marcoscaceres]

I sent a PR to use bless() instead:
web-platform-tests/wpt#37098

There are a bunch of tests that rely on "clipboard-read" that should be changed or removed:
w3c/clipboard-apis#188

The permissions policy tests are also out of date. I send an initial PR for that, but someone will need to take that over:
web-platform-tests/wpt#37103

[nairnandu]

Thank you for proposing the Clipboard API for inclusion in Interop 2023.

We wanted to let you know that this proposal was not selected to be part of Interop this year. As detailed in the issue comments, tests for this proposal rely on automation APIs not available across all three browsers. Resubmitting a proposal when tests have been updated as part of a future round of Interop would be welcome.

For an overview of our process, see the proposal selection summary. Thank you again for contributing to Interop 2023!

Posted on behalf of the Interop team.