We have tried to allow extensions to read/write from the clipboard by allowing extensions to use document.execCommand + paste/copy (like Chrome). However, writing has always had some bugs and limitations, so we introduced the ability to write images in bug 1356543, and will support more types (text / html) in bug 1344410. Bug 1312260 added support for clipboardRead, but the API is unusual (requiring a contenteditable element - bug 1340578): https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Interact_with_the_clipboard#Reading_from_the_clipboard (and even the documented example sometimes yields unexpected results - e.g. bug 1395951). There is also a desire to remove a sync IPC message for clipboard data in bug 1375022. This would probably break the documented way to read from the clipboard. To avoid these issues, the clipboard API from bug 1356543 should be extended with a method to read from the clipboard. (a standard clipboard API is being developed, but it is far from ready - https://w3c.github.io/clipboard-apis/)

(In reply to Rob Wu [:robwu] from comment #0) > Bug 1312260 added support for clipboardRead, but the API is unusual > (requiring a contenteditable element - bug 1340578): The fact that you need a contenteditable element to paste is a bug. I made it so that we always consider the copy and cut commands enabled in content documents a couple of years ago, and at the time we weren't exposing paste to any interesting targets. I would be inclined to fix that problem and allow people to use document.execCommand('paste') if they have the clipboardRead permission from within webextensions.

(In reply to Michael Layzell [:mystor] from comment #1) > (In reply to Rob Wu [:robwu] from comment #0) > > Bug 1312260 added support for clipboardRead, but the API is unusual > > (requiring a contenteditable element - bug 1340578): > > The fact that you need a contenteditable element to paste is a bug. I made > it so that we always consider the copy and cut commands enabled in content > documents a couple of years ago, and at the time we weren't exposing paste > to any interesting targets. Can this bug be fixed easily? > I would be inclined to fix that problem and allow people to use > document.execCommand('paste') if they have the clipboardRead permission from > within webextensions. Is document.execCommand('paste') a stable API? Bug 1375022 suggests that it is not available to the web, and currently WebExtensions are the only consumer.

I've submitted a patch to bug 1340578. (In reply to Rob Wu [:robwu] from comment #2) > Is document.execCommand('paste') a stable API? Bug 1375022 suggests that it > is not available to the web, and currently WebExtensions are the only > consumer. The unfortunate part about execCommand('paste') is that it is providing a synchronous API for an operation which is asynchronous on many platforms. Unfortunately I think that this is probably already locked in by the web platform, as if we receive a Ctrl-V keystroke we need to synchronously dispatch a paste event to the page already. Given that, to my understanding (from bug 1340578), chrome is already exposing this API to extensions, we may as well follow suit. ni? ehsan for his opinion.

Well, extensions can have content scripts, which can call any function that is exposed to web content. So yes, it does seem like our hands are tied here. :-/ We should follow what Chrome does. It would be nice if someone double checks to make sure that extensions in Chrome can execCommand('paste') successfully. I'm assuming that is the case.

(In reply to Rob Wu [:robwu] from comment #0) > (a standard clipboard API is being developed, but it is far from ready - > https://w3c.github.io/clipboard-apis/) The async clipboard API based on the W3C standard was released in Firefox 63. It is available from extensions and requires the same permissions as the original execCommand() method. Any further work on a WebExtensions specific API should be discontinued, so I am closing this bug.