Short: reading clipboard requires setting `contentEditable` in Firefox, but not in Chrome. Background: clipboard manipulation API came with designMode, invented by IE, and adopted by Mozilla [1]. Much later, Chrome first invented a new API for clipboard access, but later adopted to the "standard" execCommand [2], still available only to web extensions. As a consequence of this, most docs/code on the web still references setting the contentEditable, and thus works in Firefox (see code in comment below [2], a stackoverflow page from 2013, that's the first google result for this issue). Kris thinks this should be addressed, but I'm not sure this is a big issue. This is only a problem when an extension tries to paste directly into an input field on a page, but we have a very simple workaround, which is also the most common way to read the clipboard: from the background page. 1) https://developer.mozilla.org/en/Rich-Text_Editing_in_Mozilla#Executing%5FCommands 2) http://stackoverflow.com/questions/6969403/cant-get-execcommandpaste-to-work-in-chrome#answer-7100464

For context, bug 1312260 comment #29 and later.

It's not only about supporting fields with contentEditable not set, it's also about supporting "input" fields (as opposed to "textarea" fields) that have contentEditable set to true (that's not working currently).

(In reply to Geoffrey De Belie (Smile4ever) from comment #2) > It's not only about supporting fields with contentEditable not set, it's > also about supporting "input" fields (as opposed to "textarea" fields) that > have contentEditable set to true (that's not working currently). Comment 2 was about code in a content script. In the background script it even works with a "div".

Hello, I'm asking your help with an experiment with making decisions on bugs. You've been needinfo'ed on this bug. I'd like you to take one action to help this bug make progress toward a decision. The things you can do include: * If you know or have a good guess of which product and component this bug belongs to, change the product and component of the bug * If you know of the right person to ask about this bug, redirect the needinfo to them * If you cannot reproduce the bug, close it All we need you to do is one thing that will help us make a decision on the bug or resolve it. Thank you for your help with this. If you have questions, please contact emma@mozilla.com.

See bug 1397690 with context for why we want this right now. THis basically brings execCommand('paste') in line with execCommand('copy'/'cut') when used in webextensions with the clipboardRead permission.

Comment on attachment 8905604 [details] [diff] [review] Allow execCommand('paste') to be called from webextensions without a target Review of attachment 8905604 [details] [diff] [review]: ----------------------------------------------------------------- ::: editor/libeditor/tests/test_execCommandPaste_noTarget.html @@ +28,5 @@ > + > + SpecialPowers.wrap(document).execCommand("copy"); > + ok(seenCopy, "Successfully copied the text to the clipboard"); > + SpecialPowers.wrap(document).execCommand("paste"); > + ok(seenPaste, "Successfully read text from the clipboard"); Can you also add a test to ensure that a non-privileged call won't work here?

Pushed by michael@thelayzells.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e40d55e7a132 Allow execCommand('paste') to be called from webextensions without a target, r=ehsan

Hi, could you clarify for a webextension writer perspective how execCommand('paste') should now be called? I have permissions "clipboardRead", "clipboardWrite" in the manifest file, and from a content script (for extension abcTajpu2 btw), I run: let sukceso = document.execCommand("paste"); and this paste works fine in Firefox 56 (and in current Chrome although the extension isn't published there). However, for Firefox 57.0b6 it now fails to paste (but it returns true).

(In reply to Aaron Irvine from comment #10) > Hi, could you clarify for a webextension writer perspective how > execCommand('paste') should now be called? > > I have permissions "clipboardRead", "clipboardWrite" in the manifest file, > and from a content script (for extension abcTajpu2 btw), I run: > let sukceso = document.execCommand("paste"); > and this paste works fine in Firefox 56 (and in current Chrome although the > extension isn't published there). > > However, for Firefox 57.0b6 it now fails to paste (but it returns true). You should only need the clipboardRead permission. I think you may be seeing a different bug perhaps. Do you mind filing it separately please, with some information on how to reproduce it? Thanks!

Thanks. I've raised https://bugzilla.mozilla.org/show_bug.cgi?id=1408641 for that.