1619251 - [meta] Clipboard API improvements

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, task)

Description

[Tom S. (please needinfo tschuster)]

Right now Firefox only supports Clipboard.writeText and Clipboard.readText and only for WebExtensions. Chrome already supports write/read with images.

Comment 1

[Tom S. (please needinfo tschuster)]

Seems like Safari 13.1 just shipped with this API as well: https://webkit.org/blog/10247/new-webkit-features-in-safari-13-1/

Comment 2

[Thayne]

According to https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API, firefox is the only modern browser that doesn't have this. Is there any progress on this?

Comment 4

[Jukka Jylänki]

Stumbled on to this, while noticing that Safari and Chrome do implement Clipboard API, but Firefox

a) requires enabling a pref dom.events.asyncClipboard.readText, and
b) after that pref has been enabled, which exposes navigator.clipboard.readText() function, calling that function will cause an ad hoc popup dialog "Paste" to appear on the page that the user needs to click.

In Chrome, access to Clipboard is managed via the Permissions API. I wonder if Firefox has intent to implement same UX at some point? Or are there some qualms about using Permissions API for this purpose? (In particular, Permissions API is a one-off request for the lifetime of the site, whereas Firefox's current ad hoc popup appears on every paste operation)

Comment 5

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Jukka Jylänki from comment #4)

Stumbled on to this, while noticing that Safari and Chrome do implement Clipboard API, but Firefox

a) requires enabling a pref dom.events.asyncClipboard.readText, and
b) after that pref has been enabled, which exposes navigator.clipboard.readText() function, calling that function will cause an ad hoc popup dialog "Paste" to appear on the page that the user needs to click.

In Chrome, access to Clipboard is managed via the Permissions API. I wonder if Firefox has intent to implement same UX at some point? Or are there some qualms about using Permissions API for this purpose? (In particular, Permissions API is a one-off request for the lifetime of the site, whereas Firefox's current ad hoc popup appears on every paste operation)

No, we don't plan to implement same UX as Chrome. Our approach is similar to Safari's, here is our intent to prototype. We are currently working on bug 1777448 to avoid button popup when user's privacy isn't affected.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Is it possible for us to remove parity-safari and parity-chrome from this bug and move it on to any dependent bugs that correspond to actual features.

Comment 7

[Tom S. (please needinfo tschuster)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #6)

Is it possible for us to remove parity-safari and parity-chrome from this bug and move it on to any dependent bugs that correspond to actual features.

No problem. We are almost at parity now compared to 4 years ago.

Comment 8

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Thomas, we shipped the async clipboard api in Fx 127 which closed a major gap. This meta bug track a variety of issues, including test framework improvement. I think we'd like to mark webcompat:risk-* whiteboard tag on individual bugs which can reflect and help us track the risk better.

Comment 9

[Thomas Wisniewski [:twisniewski]]

we'd like to mark webcompat:risk-* whiteboard tag on individual bugs

That was my plan. I will try to assess the sub-bugs next week, but in the meantime if we need to clear the whiteboard label on the meta-bug for bookkeeping, I don't mind doing so.