clipboard-apis

clipboard-apis copied to clipboard

https://github.com/w3c/permissions/issues/175#issuecomment-671553031 from @rniwa:

Shouldn't we also remove "clipboard-write" given we wouldn't have multiple implementation support for that either??

And I think Mozilla also have no intention to implement that. (cc @mbrodesser, @annevk)

Oh, actually https://github.com/w3c/permissions/pull/246 already removed clipboard-write. I'll open a PR then.

A change like this should be discussed in the Web Editing WG before it can be made. Given its use in Chromium I doubt we will reach consensus on its removal.

@travisleithead @johanneswilm @snianu

I'm updating the MDN Clipboard API docs to reflect the current state of play. The situation is confusing. Could I get confirmation/denial of the following:

• read()/readText():
  • The consensus and spec intent is to gate reading on transient activation rather than using clipboard-read permission
  • The clipboard-read permission has been removed from the permissions API.
  • The clipboard-read permission has been partially removed from the Clipboard API but is still referred to in a few places (I assume these will be cleaned up at some point).
  • FF and Safari gate on transient activation and don't use the permission.
  • Chrome gates on clipboard-read and if it is granted does not require transient activation. (result from testing current Chrome)
  • Chrome might reasonably be expected to change to match other browsers here, as there is consensus to remove the clipboard-read permission.
• write()/writeText():
  • The spec team intent is to gate writing on transient activation rather than using clipboard-write permission
  • The clipboard-write permission has been removed from the permissions API but without consensus from Chrome.
  • The clipboard-write permission is still in the Clipboard API
    • Spec mentions the permission has been removed
    • this issue indicates an intent/desire to remove it and use transient activation
    • this issue indicates consensus not reached, and looks like is not being chased.
  • FF and Safari do not use write permissions and never will.
  • Chrome gates on clipboard-write and if it is granted does not require transient activation.

Given the removed permissions, I'm not sure what is expected by the spec/spec team. Can you give me some kind of view on where the spec and browsers are heading? My current plan is to assume that transient activation for read/write is what is expected and document the read/write permissions as incompatible, but I'd rather be "right".

As a developer of a web application that is often used inside an iframe, the behavior in Safari and Firefox where clipboard writes require a user gesture, but do not require allow="clipboard-write" on the iframe, is much more convenient. Is there any possibility of Chrome aligning on that behavior? I'm not sure if any Chrome developers are following this issue, if not I can report on the Chrome-specific bug tracker instead.

Is there any possibility of Chrome aligning on that behavior?

Adding @evanstade and @inexorabletash to comment on this. I'm not sure if we can remove the clipboard read/write permissions as removing those permissions would break the chrome remote desktop clipboard sync scenarios. Note that a recent change was made in Chromium to allow web authors to access clipboard within the copy/paste event handler, so that might work for your use case @robertknight ?

Note that a recent change was made in Chromium to allow web authors to access clipboard within the copy/paste event handler, so that might work for your use case @robertknight ?

Our use cases generally look like the MDN example where a clipboard API to write text or HTML is called when a button is clicked. For context our app is an annotation / commenting tool for HTML / PDF and there are buttons to copy comments to the clipboard, so they can be easily pasted into a document or spreadsheet.

I tried the latest Chrome Canary release and it seems that iframes still need the clipboard-write permission to enable writing to the clipboard in response to a button click.

@robertknight Since this question is specific to Chromium, please open a crbug and let's discuss with Chromium folks there.

Still seems like a good chance to discuss about this, though. Are there known use cases other than clipboard sync that need those permissions, that the aforementioned chromium change can't deal with? Should the implementations show an extra icon somewhere as browsers do with audio and video record?

where clipboard writes require a user gesture, but do not require allow="clipboard-write"

Chromium is making a change in this space soon: https://chromestatus.com/feature/5167870134976512

However, a generic user gesture/activation will still not be enough to write to the clipboard beyond plain text. What types does your app attempt to write? Perhaps there is an argument to extend the plain text behavior to all built-in types.

Should the implementations show an extra icon somewhere as browsers do with audio and video record?

This is what Chromium does, however cross-origin iframes don't get to request permissions (some? all? not sure).

What types does your app attempt to write? Perhaps there is an argument to extend the plain text behavior to all built-in types.

Plain text and HTML. Extending the change to HTML would be helpful as it could avoid situations where some copy-to-clipboard functionality in the app works, but some does not, if a third-party embedding us hasn't added the clipboard-write permission to their iframe.