xpra icon
Bug tracker and wiki

Opened 16 months ago

Last modified 2 months ago

#1844 new enhancement

async clipboard api

Reported by: Antoine Martin Owned by: zaveri
Priority: critical Milestone: 3.0
Component: html5 Version: 2.3.x
Keywords: Cc:

Description (last modified by Antoine Martin)

See Unblocking Clipboard Access: It's a replacement for execCommand-based copy & paste that has a well-defined permissions model and doesn't block the page.

MDN: Navigator clipboard.

Original html5 clipboard tickets: #842, #1461

Change History (7)

comment:1 Changed 5 months ago by Antoine Martin

See also related work in #812

comment:2 Changed 3 months ago by Antoine Martin

Status: newassigned

For images, see #2312

comment:3 Changed 3 months ago by Antoine Martin

Priority: majorcritical

Blocker for #2312

comment:4 Changed 3 months ago by Antoine Martin

Description: modified (diff)


  • r22834 new async api calls
  • r22837 answer clipboard requests
  • r22838 workaround PRIMARY + CLIPBOARD overwriting values
  • r22839 don't bother synchronizing PRIMARY if we have the new async API
  • r22840 stricter test for navigator.clipboard API availability

Important: just found information on clipboardchange event in w3c: Async Clipboard API. This is not supported in any browser yet.
This means we would not necessarily have to claim the clipboard every time we get a token, we could rely on those events to notify the server.
For chrome: onClipboardDataChanged.

Maybe we should query the Permissions API rather than just checking if the method exists?
See Asynchronous Clipboard API Sample


  • Chrome 75.0.3770.51 (Official Build) beta (64-bit) Linux: OK (connecting to localhost using websocket)
  • Chrome 74 MS Windows: OK via https, otherwise legacy mode
  • Firefox 67 Linux: legacy mode
  • Firefox 67 MS Windows: legacy mode

The Firefox results are surprising since they claim to support the async API since V63, but this matches the results from this test.
The spec says: Firefox only supports reading the clipboard in browser extensions, using the "clipboardRead" extension permission.

Then there are also issues with "secure contexts": works for localhost, otherwise https is required, etc..

Last edited 3 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 2 months ago by Antoine Martin

IE fixes in r22862. (no arrow functions)

The problem with the permissions API is that if the user denies the request, we cannot ask again and we're left with a non-functional API..
To restore things, one has to visit chrome://settings/content/siteDetails?site=https%3A%2F%2Fgooglechrome.github.io%2F (chrome), or follow steps similar to How do I make Chrome forget a “no” to geolocation on a site?

Last edited 2 months ago by Antoine Martin (previous) (diff)

comment:6 Changed 2 months ago by Antoine Martin

Also fixes #2292

comment:7 Changed 2 months ago by Antoine Martin

Owner: changed from Antoine Martin to zaveri
Status: assignednew

For testing: the html5 client will print a message to the console indicating if it's using the old or new (async) clipboard code. (message actually fixed in r22911)

Tweaks and better compatibility for legacy mode in r22918.
IE compatibility fixes in r22919 + r22920.

The new code saves having to synchronize the PRIMARY selection constantly, we do that with the old code just in case we get a clipboard copy request from the browser so that we can provide a response instantly. (this is the synchronous clipboard)
With the new async code, we populate the clipboard only when needed.

Note: See TracTickets for help on using tickets.