As a developer I might want to create features that include copying arbitrary string to the user's clipboard. Currently I can't do this with web extensions but in the Add-on SDK it was very straightforward: https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/clipboard I might even go as far as to say, we should simple re-use the SDK implementation and hang it off of browser.clipboard.*

To be discussed at the WebExtensions Triage meeting on March 21. Agenda: https://bugzilla.mozilla.org/show_bug.cgi?id=1344410

Oops -- I added the wrong link! The agenda can be found here: https://docs.google.com/document/d/1xM6iKOSGo9cDWw3ZA27PT-AVlx1Mvd79sxC6pYNhBqU/edit?usp=sharing

The clipboard API should support setting data with arbitrary content types, or at a minimum at least the 3 flavors that the Add-on SDK API supports: text, HTML, image. Our Page Saver add-on (XPCOM) supports capturing a web page as an image and placing it on the clipboard, but our Page Saver WE version (WebExtensions) cannot provide a similar feature today.

This API request has been discussed during the last WebExtensions APIs triage meeting and it has been approved. A priority will be assigned to it in the next "Triage WebExtensions" meeting.

Good news.. A clipboard API (at least a write API) is greatly needed. Developers often need to save data to clipboard from background script. At the moment, the hacking method of injecting it via tabs.executeScript & document.execCommand('copy') is messy and fails on a number of pages restricted by Firefox (ie AMO, About:* and other unsupported schemes) Even in content script, for example copying a page URL or title, involves creating, setting, selecting, execCommand, and removing; unnecessary elements into DOM just for the sake of copying a string.

From what I gather Chrome had a clipboard API up until Chrome 13, at which time they removed the API and focused instead on document.execCommand(). See also: https://stackoverflow.com/questions/6925073/copy-paste-not-working-in-chrome-extension Making document.exeCommand() work well should probably our first priority and then all we have to do is provide a reasonable library to that (perhaps).

In many aspects, Firefox has not been following Chrome so whether Chrome supports it or not is not as relevant as one might think. What is wrong with Firefox leading instead of following (as, for example, is the case with context-menu tab context)? IMHO, the issue is the scope. document.exeCommand() is a Web API and meant for content scope. While Web-extension's content script functions in the same scope, the rest of it (eg background scripts, don't). OS clipboard is closer to the browser and background scope than web page's content scope. At the moment, copying a string to clipboard involves moving between scopes multiple times just for this purpose which seems inefficient (besides the other hurdles involved). For example, I have a Tab based web-extension (in tab context) which does not have any content script at all and does not have anything to do with content whatsoever. Copying a tab title or URL (which are available to context-menu function) forces the extension to interact with content unnecessarily.

It seems chrome proposed a simpler web API as well, that they're now implementing and that someone from Mozilla was involved in designing. It does still seem very experimental, but seems to have landed in Blink. Spec: https://github.com/garykac/clipboard/blob/master/clipboard.md Blink implementation bug: https://bugs.chromium.org/p/chromium/issues/detail?id=677564

See https://bugzil.la/1356543#c32. If my API proposal is approved I will work on this bug (either as a part of bug 1356543, or a follow-up here).

In bug 1356543 comments 32 you says: > Out of scope: Reading from the clipboard. > - Extensions can already read from the clipboard with document.execCommand('paste') and a contentEditable element (even in the > background page - see bug 1312260, and bug 1340578 for compatibility notes). Please also implement a reading API. For my use case (copy last URL from clipboard as new tab page in New Tab Override) I only need read access. And I don't understand why a nice writing API should be implementend but not a nice reading API. Also https://github.com/garykac/clipboard/blob/master/clipboard.md contains the reading part. Why only implement the half? One great thing about WebExtensions is the fact that there are great and easy-to-use APIs for various thing. The document.execCommand() is a hack at best and not easy to use. I still don't understand how to use it to read the current clipboard content. The clipboard API in the add-on SDK was simple, it was a perfect API from the add-on developer's point of view. It was a clear API and couldn't be easier to use. Why not implementing a simple API like all the other WebExtension APIs? Clipboard access is the one exception in the WebExtension world - seems to be somehow possible, but there is neither a nice API nor an easy to understand documentation. Thank you.

(In reply to Sören Hentzschel from comment #11) > In bug 1356543 comments 32 you says: > > > Out of scope: Reading from the clipboard. > > - Extensions can already read from the clipboard with document.execCommand('paste') and a contentEditable element (even in the > background page - see bug 1312260, and bug 1340578 for compatibility notes). > > Please also implement a reading API. For my use case (copy last URL from > clipboard as new tab page in New Tab Override) I only need read access. And > I don't understand why a nice writing API should be implementend but not a > nice reading API. Also > https://github.com/garykac/clipboard/blob/master/clipboard.md contains the > reading part. Why only implement the half? Because eventually, the web platform will have a standard API to read from the clipboard, and it is a non-goal of WebExtensions to duplicate APIs that already exist on the web platform. > One great thing about WebExtensions is the fact that there are great and > easy-to-use APIs for various thing. The document.execCommand() is a hack at > best and not easy to use. I still don't understand how to use it to read the > current clipboard content. Reading is relatively easy: document.addEventListener('paste', function(event) { var text = event.clipboardData.getData('text'); console.log(text); // Prints something if there is text on the clipboard. }, {once: true}); document.execCommand('paste'); // Requires clipboardRead permission Pasting ought to be easy too, but there are bugs that prevent it from being reliable in background pages. That is why I will add a specific bug-free method to copy data to the clipboard. > The clipboard API in the add-on SDK was simple, it was a perfect API from > the add-on developer's point of view. It was a clear API and couldn't be > easier to use. Why not implementing a simple API like all the other > WebExtension APIs? Clipboard access is the one exception in the WebExtension > world - seems to be somehow possible, but there is neither a nice API nor an > easy to understand documentation. Documentation will be fixed once these APIs land in Firefox 57.

> Because eventually, the web platform will have a standard API to read from the clipboard, and it is a > non-goal of WebExtensions to duplicate APIs that already exist on the web platform. Eventually and we aren't there yet. I think we are down the path of trying to make it possible to do clipboard easily unit the web platform is there. I would recommend adding this to remove developer confusion and make it easier. We will deprecate when the web platform gets there.

(In reply to Rob Wu [:robwu] from comment #12) > > reading part. Why only implement the half? > > Because eventually, the web platform will have a standard API to read from > the clipboard, and it is a non-goal of WebExtensions to duplicate APIs that > already exist on the web platform. Has this "eventually" come yet? > > > One great thing about WebExtensions is the fact that there are great and > > easy-to-use APIs for various thing. > Pasting ought to be easy too, but there are bugs that prevent it from being > reliable in background pages. That is why I will add a specific bug-free > method to copy data to the clipboard. What are the bugs, and is this on any agenda anywhere? If not, another reason to keep this bug alive. > > The clipboard API in the add-on SDK was simple, it was a perfect API from > > the add-on developer's point of view. It was a clear API and couldn't be > > easier to use. Why not implementing a simple API like all the other > > WebExtension APIs? Clipboard access is the one exception in the WebExtension > > world - seems to be somehow possible, but there is neither a nice API nor an > > easy to understand documentation. > > Documentation will be fixed once these APIs land in Firefox 57. Until then, what? Also, can some of these be brought into 56, so people have a chance to see their extensions start working as web-ext before fully committing to 57? (In reply to Andy McKay [:andym] from comment #13) > > Because eventually, the web platform will have a standard API to read from the clipboard, and it is a > > non-goal of WebExtensions to duplicate APIs that already exist on the web platform. > > Eventually and we aren't there yet. I think we are down the path of trying > to make it possible to do clipboard easily unit the web platform is there. I > would recommend adding this to remove developer confusion and make it > easier. We will deprecate when the web platform gets there. Agree 100%.

(In reply to Worcester12345 from comment #14) > Also, can some of these be brought into 56, so people have a chance to see > their extensions start working as web-ext before fully committing to 57? Uplifts to Firefox 56, currently in beta and close to release, are done for security or stability reasons. This bug does not meet those criteria. See https://wiki.mozilla.org/Release_Management/Uplift_rules for more.

From https://developer.mozilla.org/en-US/docs/Web/API/Clipboard For WebExtensions, you can request the clipboardRead and clipboardWrite permissions to be able to use clipboard.readText() and clipboard.writeText(). Content scripts applied on HTTP sites do not have access to the clipboard object. See extensions in Firefox 63. https://blog.mozilla.org/addons/2018/08/31/extensions-in-firefox-63/ So I think this bug can be closed.

So just to be clear: copying to the clipboard can be done like this: navigator.clipboard.writeText(text); And reading like this: navigator.clipboard.readText().then((text) => { console.log(text); }); Mike, can you close this bug?

Thanks for poking this bug.