Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to implement: Async Clipboard API

454 views
Skip to first unread message

Nika Layzell

unread,
May 14, 2018, 5:05:48 PM5/14/18
to dev-platform
In about a week, my intern will be starting. As an initial project, I
intend for her to implement the Async Clipboard API.

Summary: The Async Clipboard API provides a more modern and performant
interface to the user's clipboard. This API is intended to replace many
consumers of the existing `document.execCommand("copy"/"cut")`.

Example Usage:
navigator.clipboard.writeText("text").then(...)

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1461465

Link to standard: https://w3c.github.io/clipboard-apis/#async-clipboard-api

Platform coverage: All

Estimated or target release: Firefox 63 (estimated)

Preference behind which this will be implemented:
'dom.events.asyncClipboard'
The full `write`/`read` APIs will be exposed to the web behind an
additional
preference of 'dom.events.asyncClipboard.dataTransfer', so we can ship
the text APIs separately.

DevTools bug: N/A

Do other browser engines implement this?
Chrome: Shipped (since version 66)
Edge, Safari: Public Support (according to
https://www.chromestatus.com/features/5861289330999296)

web-platform-tests: A test for this API has already been created by the
chrome team (
https://searchfox.org/mozilla-central/rev/2b9779c59390ecc47be7a70d99753653d8eb5afc/testing/web-platform/tests/clipboard-apis/async-navigator-clipboard-basics.https.html
)

Secure Contexts Only: Yes, this API will only be exposed to secure contexts.

Security & Privacy Concerns: This API exposes no new capabilities to the
web platform. Instead, it provides a more performant and ergonomic API to
replace most users of `execCommand("copy"/"cut")`. -- We do not intend to
expose the ability to read from the clipboard (the Clipboard.read and
Clipboard.readText APIs) to the web at this time. These APIs will only be
usable by extensions which have requested the appropriate permissions. --
Exposing `Clipboard.write` (the full DataTransfer API) to the web will also
occur behind a separate preference.

Martin Stransky

unread,
May 15, 2018, 4:04:08 AM5/15/18
to dev-pl...@lists.mozilla.org
That would be really awesome to get rid of all Gtk+/Clipboard hacks we
have there to transfer async clipboard on Linux to sync at Gecko....so
does it mean we can provide async clipboard only on toolkit/widget code
level?

ma.
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Nika Layzell

unread,
May 15, 2018, 11:08:22 AM5/15/18
to Martin Stransky, dev-platform
Unfortunately, we can't get rid of the Gtk+/Clipboard hacks yet. There is
still a synchronous API for reading the clipboard
(document.execCommand("paste")) which is exposed to webextensions.

Beyond that, we'd need to read the clipboard asynchronously for ctrl-V
paste events. For now, I don't intend to get my intern to actually modify
the platform code to make it async, but rather to expose the new API to web
content.

On Tue, May 15, 2018 at 4:03 AM, Martin Stransky <stra...@redhat.com>
wrote:
0 new messages