New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 20 users

Issue metadata

Status: Duplicate
Merged: issue 677564
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Sign in to add a comment

Implement asynchronous clipboard API

Project Member Reported by, Mar 9 2016

Issue description

It is currently possible to copy to the clipboard on the open web using document.execCommand(“copy”). Although it is usually better to build on existing standards, the current clipboard API is particularly annoying to use and has some limitations that make it harder to bring more clipboard-related features to the open web.

Hallvord Steen of Mozilla has been working on a Clipboard API [1], but I reached out to him yesterday based on [2] about working on a new clipboard API [3], which I'm tentatively referring to as navigator.clipboard (to distinguish it from the existing API).

The API would look roughly like this:

    navigator.clipboard.copy(clipboardData).then(function() {
      console.log("Copied successfully!");

    navigator.clipboard.paste().then(function(clipboardData) {
      console.log("Here's what's on the clipboard:", clipboardData);

    navigator.clipboard.addEventListener(“change”, function(clipboardData) {
      console.log("The clipboard contents have changed to:", clipboardData);

Details are still in the air, including:
- the exact format of clipboardData,
- function names: "copy"+"paste" vs. "read"+"write",
- interaction with current "copy" and "paste" events on the document
- browser-specific restrictions about which APIs are available from which contexts (e.g. open web, extensions, subframes, background tabs, workers), and which APIs to gate behind which permissions.

## Benefits

- Asynchronous: navigator.clipboard can use the same Promise-style API as other powerful web features. This:
  - Allows user agents to show a permission prompt without blocking the page in the same way as other APIs.
  - Allows sanitizing security-sensitive data types without blocking the main page.
- Easy to use: document.execCommand() has a lot of baggage from its designMode origins, and is difficult to use correctly (see Appendix B for more).

In particular, this will help us move forward with the following three clipboard features in Chrome:
1. Paste on the open web.
2. Copying images to/from the clipboard.
3. A standard way to listen for clipboard changes.

There is significant in Chrome and Google to make this happen:
- #1 and #2 would allow Google Docs to stop relying on an extension in order to interact with the clipboard from Docs, and
- #3 is of interest to Chrome Remote Desktop.

See [3] for a strawman proposal and [4] for a doc about considerations specific to Chrome (e.g. permission handling).

jamiewalch@ (from Chrome Remote Desktop) will probably be leading the effort from the Chrome side, but I'm assigning myself as initial owner before I hand things off.

Components: UI>Browser>Permissions Blink>DataTransfer Security>UX Internals>Permissions
Labels: -Type-Bug OS-All Type-Feature
Passing the torch to Jamie.
garykac@: Any interesting updates?

Safari 10 just shipped `document.execCommand("copy")` support, which surfaced feature detection bugs with `document.queryCommandEnabled` [1][2]

[1]  Issue 649820 
For what it's worth, I've shimmed my wrapper library onto the proposal  (ignoring DataTransfer support) at

Comment 6 Deleted

Comment 7 Deleted

Comment 8 Deleted

Summary: Implement asynchronous clipboard API (was: Implement a new navigator.clipboard API)
Mergedinto: 677564
Status: Duplicate (was: Assigned)
Deduping into the bug referring to the latest spec work for simplicity.

Comment 11 Deleted

I need something like this that's not attached to the design mode. 

My use case is manually setting image data to the clipboard. It may not be in the context of a click event or copy event. I'd be satisfied with Chrome showing a permissions prompt to a site wide "Allow domain to Write to Clipboard" or a "Write image to clipboard" prompt. 

If you are looking for design considerations you can model it after the Flash Clipboard API as many developers are familiar with the API for the Flash fallback methods:

NB: If this bug is not followed please let me know where to post this comment. 
If you're not doing this in response to an event, how does the user know that you've modified their clipboard data?
It is in response to an event sort of. They are pressing a button, "Copy image to clipboard" but my application runs in a plugin and that would call out to the browser to write to the clipboard. The plugin content captures the click event and so as far as I know it never reaches the browser. 

Right now, AFAIK, there's no way to save bitmap data to the clipboard. So if I'm able to make a call to JS, pass a base64 string through ExternalInterface, I'm fine having a window pop up asking the user if they want to copy the image to the clipboard. 

Sign in to add a comment