Filed this solely to have a tracking bug.

Once enabled, the documentation at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features should be updated.

Also, when a bug for shipping this feature is created (I didn't see one yet), please add the dev-doc-needed flag, so it'll be documented on MDN.

Sebastian

This API is necessary to enable copying of image content into the clipboard, which some web application like gitea now offer. I have been using it with the pref enabled since a few months now without issue.

:saschanaz, when we enable async clipboard, will we also change document.queryCommandSupported('paste') to return true? There is at least one site which will expect that to be true before context-menu pasting will work properly on their editor in Firefox, even with async clipboard (see https://github.com/webcompat/web-bugs/issues/123378 ).

That implies document.execCommand('paste') should succeed at the point of the call, which is very separate thing from Async Clipboard. And I don't think Chrome returns true there either.

Per the site comment it seems Godbolt copypasted that check from Microsoft's Monaco: https://github.com/microsoft/vscode/blob/b8fe761e224d85fe5c80dc3dfb9976b38d3c36cc/src/vs/editor/contrib/clipboard/browser/clipboard.ts#L27-L30.

Per https://github.com/microsoft/vscode/pull/104646 it looks like someone spoiled the feature detection while working on ancient code, which to be fair is a hard job! But that check is still bad, I think we should fix Monaco and Godbolt instead.

Good thinking, I've filed https://github.com/microsoft/vscode/issues/184958 and will re-open the webcompat bug to try to reach out to the developer (or to remind us to create a site-intervention when the time comes).

asyncClipboard is also required to paste content into remote desktops with Apache Guacamole.

• Besides settting dom.events.testing.asyncClipboard to true as explained here https://sudoedit.com/firefox-async-clipboard/
• on my laptop (tested also with a colleague) it appears that dom.events.asyncClipboard.clipboardItem is also needed

I'm wondering if/when these settings can be enable by default?

https://hg.mozilla.org/mozilla-central/rev/e5420eb5fcfe

:edgar would you like to mention this in the nightly only release notes? Could you consider nominating this for a release note? (Process info)

Yes, I think it's worth to mention this in the nightly only release notes.

Release Note Request (optional, but appreciated)
[Why is this notable]: New web APIs (navigator.clipboard.readText()/read()/write())
[Affects Firefox for Android]: Yes
[Suggested wording]: The remaining part of the async clipboard API has been enabled. A paste context menu will appear for the user to confirm when attempting to read clipboard data not provided by the same-origin page.
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API

Thanks, added to the Fx122 nightly release notes, please allow 30 minutes for the site to update.

FF122 MDN docs for this can be tracked in https://github.com/mdn/content/issues/31104

Can I please confirm exactly what has changed for the browser compatibility. My understanding is that:

• Firefox now supports the whole spec API for both Clipboard and ClipboardItem in both extensions and in normal pages except for ClipboardItem.presentationStyle and the clipboardchange event.

• Clipboard.write()

  • This is now supported in preview/beta whereas previously it was behind preference.

  • The BCD entry had this note:

    "Writing to the clipboard is available without permission in secure contexts and browser extensions, but only from user-initiated event callbacks. Browser extensions with the <code>"clipboardWrite"</code> permission can write to the clipboard at any time."

    I am assuming it was true previously if the preference was enabled. Now the feature is always enabled, is it still true?

• Clipboard.writeText() had the same note but was introduced in FF66 according to BCD. I assume the note is correct and nothing changes?

• Clipboard.read()

  • This is now supported in preview/beta whereas previously it was behind preference.

  • This previously had the note:

    "Firefox only supports reading the clipboard in browser extensions, using the <code>"clipboardRead"</code> extension permission.".

  • Can you confirm that? I think this means that previously it was supported only for browser extensions, but now it is supported for content too?

  • Should we then have a note like:

    Reading the clipboard secure contexts and browser extensions, but only from user-initiated event callbacks. A paste-context confirmation prompt will be displayed the user attempts to read from data that isn't from a same-origin page. Browser extensions with the <code>"clipboardRead"</code> permission can read from the clipboard at any time."

• readText()

  • BCD marks this as not supported but had the same note as read().
  • The source indicates this is enabled by dom.events.asyncClipboard.readText
  • So my assumption is that this previously worked for browser extensions but now works for content too. Right?

From the current docs we also have:

• Clipboard.write()
  • This note - is it still true?

    Note: For parity with Google Chrome, Firefox only allows this function to work with text, HTML, and PNG data.

(In reply to Hamish Willee from comment #14)

• Firefox now supports the whole spec API for both Clipboard and ClipboardItem in both extensions and in normal pages except for ClipboardItem.presentationStyle and the clipboardchange event.

We don't support clipboardchange event.
We have already implemented ClipboardItem.presentationStyle in bug 1619947.

• Clipboard.write()

  • This is now supported in preview/beta whereas previously it was behind preference.

  • The BCD entry had this note:

    "Writing to the clipboard is available without permission in secure contexts and browser extensions, but only from user-initiated event callbacks. Browser extensions with the <code>"clipboardWrite"</code> permission can write to the clipboard at any time."

    I am assuming it was true previously if the preference was enabled. Now the feature is always enabled, is it still true?

"but only from user-initiated event callbacks" is not accurate, I suggest something like "but is allowed to be called when the contexts have transient activation".

• Clipboard.writeText() had the same note but was introduced in FF66 according to BCD. I assume the note is correct and nothing changes?

Yes, nothing changes for Clipboard.writeText().

• Clipboard.read()

  • This is now supported in preview/beta whereas previously it was behind preference.

  • This previously had the note:

    "Firefox only supports reading the clipboard in browser extensions, using the <code>"clipboardRead"</code> extension permission.".

  • Can you confirm that? I think this means that previously it was supported only for browser extensions, but now it is supported for content too?

  • Should we then have a note like:

    Reading the clipboard secure contexts and browser extensions, but only from user-initiated event callbacks. A paste-context confirmation prompt will be displayed the user attempts to read from data that isn't from a same-origin page. Browser extensions with the <code>"clipboardRead"</code> permission can read from the clipboard at any time."

Yes, now it is also available in secure contexts. The same suggestion for user activation mentioned above also applies here.

• readText()

  • BCD marks this as not supported but had the same note as read().
  • The source indicates this is enabled by dom.events.asyncClipboard.readText
  • So my assumption is that this previously worked for browser extensions but now works for content too. Right?

Yes, and the behavior for paste-context confirmation and user activation also applies to readText().

Thanks!

(In reply to Hamish Willee from comment #15)

From the current docs we also have:

• Clipboard.write()
  • This note - is it still true?

    Note: For parity with Google Chrome, Firefox only allows this function to work with text, HTML, and PNG data.

Yes, we only support text/plain, text/html and image/png.

Thanks @edgar. Helpful, except now I realise that I wasn't precise enough in my questions

In browser compatibility we should only document things that are off-spec and anything that is in spec and web app developer we should mention in the docs. I worry that that these notes are expected behaviour when compared to the spec, so should not be mentioned in BCD at all. In addition there are spec changes around removal of permissions that seem to have been been done in a partial way - making it hard to read.

Can you confirm specifically:

• Clipboard.write()

  • Currently following our discussion the note says:

    Writing to the clipboard is available without permission in secure contexts and browser extensions, but only when the contexts have transient activation.
    Browser extensions with the "clipboardWrite" permission can write to the clipboard at any time.

  • Permissions API is removed(ish) from the spec, and what the spec seems to say is:

    • The feature is only available in secure contexts.
    • Requires a gesture (transient activation)
    • There also seems to be option for the user agent to add more restrictions if desired.
    • There is some messy leftover info around permissions that hasn't been removed that implies you might not need transient activation - I plan to ignore that

  • So I think that we're saying is that for writing:

    • outside of browser extensions we largely match the spec - require secure context and transient activation. That means we don't need to mention it.
    • Browser extensions
      • require transient activation and secure context if don't have write permission (?)
      • if extension has write permission you can write without transient activation or secure context (?)
      • Is there a spec for browser extensions, and is the behaviour matching that spec or different? If it is on spec we don't need to mention at all. If it is off spec then we do.

• Clipboard.writeText()

  • You said Yes, nothing changes for Clipboard.writeText(). Same questions as above really. Do you mean that the user callback stuff is is not the same as transient activation so the current description stands? (and we're off spec for this method?).

• read() and readText

  • I assume that whatever the notes say, it should be the same for both?

  • The spec indicates read() and takes some options Promise<ClipboardItems> read(optional ClipboardUnsanitizedFormats formats = {}); but the FF IDL does not. Do we know if any browsers implement this formats option, and does Firefox plan to do so?

  • Same questions as before.

    • Spec says (I think): "Reading works if you are in a secure context AND you have transient activation."
    • I "think" the FF matches this BUT you additionally get a Paste-prompt if pasting content that originates from a cross-origin page". Is that right?
      • So here all we need to mention is the paste prompt when reading text that was previously pasted from a cross origin context??
    • Same comment for the browser extensions as for the write methods - is there a spec for this, and is it expected that your extension can read anywhere if it has that permission granted/require secure context/require transient activation?

Sorry to be painful, but it could be we need no notes, or we need to be more precise.

PS I have marked the docs work as complete, but I might need to adjust based on the response to ^^^^.

(In reply to Hamish Willee from comment #18)

- So I think that we're saying is that for writing:
  - outside of browser extensions we largely match the spec - require secure context and transient activation. That means we don't need to mention it.
  - Browser extensions
    - require transient activation and secure context if don't have write permission (?)
    - if extension has write permission you can write without transient activation or secure context (?)

It's only available on secure context, extension with write permission can write without transient activation.

    - Is there a spec for browser extensions, and is the behaviour matching that spec or different? If it is on spec we don't need to mention at all. If it is off spec then we do. 

AFAIK, there is no formal web extension spec yet, but there is mdn page for clipboard permission: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#clipboard_access.

• Clipboard.writeText()
  • You said Yes, nothing changes for Clipboard.writeText(). Same questions as above really. Do you mean that the user callback stuff is is not the same as transient activation so the current description stands? (and we're off spec for this method?).

Oh, I meant to say that our behavior for Clipboard.writeText() has not changed after enabling the pref.
The transient activation requirement and web extension behavior for writeText() and write() are the same.

• read() and readText
  • I assume that whatever the notes say, it should be the same for both?

Yes.

• The spec indicates read() and takes some options Promise<ClipboardItems> read(optional ClipboardUnsanitizedFormats formats = {}); but the FF IDL does not. Do we know if any browsers implement this formats option, and does Firefox plan to do so?

This is an optional feature and only Chromium implement this, there is a spec pr to make it more clear.
Firefox and Safari have no plan to support it.

• Same questions as before.
  • Spec says (I think): "Reading works if you are in a secure context AND you have transient activation."
  • I "think" the FF matches this BUT you additionally get a Paste-prompt if pasting content that originates from a cross-origin page". Is that right?

The Paste-prompt is defined in the spec,
but we suppress if pasting content that originates from a same-origin page.

  - So here all we need to mention is the paste prompt when reading text that was previously pasted from a cross origin context??

I think we need to mention that there is no paste prompt when pasting content from a same-origin page instead.

- Same comment for the browser extensions as for the write methods - is there a spec for this, and is it expected that your extension can read anywhere if it has that permission granted/require secure context/require transient activation?

No, there is no formal spec for web extension yet.

Right now, read()/readText() is only allowed on extension that has read permission (can read without transient activation and no paste prompt).
There is a bug 1773681 to change the behavior, we could adjust document there I think.

Sorry to be painful, but it could be we need no notes, or we need to be more precise.

Thanks for working on this!

This has been enabled on Nightly for 3 cycles now. Per our policy, removing this from the Nightly release notes. Feel free to nominate again for train-specific release notes when this is ready to ride the trains to Release.