[Web-compat] Align clipboard API requirements with Chrome

RESOLVED FIXED in Firefox 57

Status

()

defect
RESOLVED FIXED
2 years ago
9 months ago

People

(Reporter: zombie, Assigned: Nika)

Tracking

unspecified
mozilla57
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fixed)

Details

(Whiteboard: [ele:1b])

Attachments

(1 attachment)

Reporter

Description

2 years ago
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
Reporter

Comment 1

2 years ago
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".

Updated

2 years ago
Component: WebExtensions: Compatibility → General
Product: Toolkit → Core
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.
Flags: needinfo?(rforbes)
Whiteboard: [ele:1b]
Reporter

Updated

2 years ago
Duplicate of this bug: 1375794

Updated

2 years ago
Depends on: 1397690
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.
Attachment #8905604 - Flags: review?(ehsan)

Comment 7

2 years ago
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?
Attachment #8905604 - Flags: review?(ehsan) → review+
Assignee: nobody → michael

Comment 8

2 years ago
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
https://hg.mozilla.org/mozilla-central/rev/e40d55e7a132
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57

Comment 10

2 years ago
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).

Comment 11

2 years ago
(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!
Flags: needinfo?(rforbes)
You need to log in before you can comment on or make changes to this bug.