1998195 - Expose execCommand("paste") with a pop-up menu to web content.

Status: RESOLVED FIXED

(Core :: DOM: Copy & Paste and Drag & Drop, enhancement)

Description

[Jeff Muizelaar [:jrmuizel]]

This is one of our options for supporting programmatic paste on Google Docs.

Safari does this and Google Docs uses it there for paste support.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Edgar is going to look into how practical this would be.

Comment 2

[Edgar Chen [:edgar]]

Safari uses the same security model as the Async Clipboard API for execCommand("paste"); that is, a pop-up menu is shown to request user confirmation if the clipboard data didn't originate from the same origin page. I think this wouldn’t be hard to implement based on our current nsIClipboard API, though it would require spinning the event loop since execCommand() is a synchronous API.

However, the execCommand() is marked as deprecated, while the newer Async Clipboard API is available. I’m concerned that exposing this deprecated API directly to web content could encourage developers to continue using it instead of migrating to the newer API. We could limit its exposure to certain domains, but I’m also wondering if there’s a more flexible and controllable approach we could take to expose it safely, particularly for the Google Docs case.

Currently, execCommand("paste") is available to the WebExtensions that have the clipboardRead permission in Firefox, and it returns false if the permission is not granted. I'm thinking of falling back to the pop-up menu security model when the permission is not granted in WebExtensions. So that we could expose the execCommand("paste") with popup menu support through interventions to web content while still gating it on explicit user confirmation. This also aligns with what we plan to do for the Async Clipboard API in WebExtensions (bug 1773681).

Comment 3

[Edgar Chen [:edgar]]

Hi Rod, do you think the clipboard API changes in WebExtensions look reasonable to you? Thanks!

Comment 4

[Rob Wu [:robwu]]

Extensions already have a way to read from the clipboard with document.execCommand if they want to, through the "clipboardRead" permission.

Since there are already good alternatives (using clipboardRead permission or navigator.clipboard) and spinning the event loop is not ideal, I recommend against adding special extension-only behavior to execCommand without the clipboardRead permission. If you end up implementing something general for the web, I'd be okay with that to also be available to extensions, but I don't see a necessity in doing something special just for extensions.

Here is an explanation of how extensions can already read from the clipboard and expose that capability to the web page: https://bugzilla.mozilla.org/show_bug.cgi?id=1996130#c1
and a code example of how to do so: https://bugzilla.mozilla.org/show_bug.cgi?id=1996130#c3

Comment 5

[Edgar Chen [:edgar]]

Attachment: Bug 1998195 - Expose execCommand("paste") with a pop-up menu to web content; r?smaug!,masayuki!

Comment 6

[Edgar Chen [:edgar]]

Attachment: 0001-Add-a-JS-intervention-to-make-Google-Suite-to-use-ex.patch

This is a test-purpose intervention, modified from https://phabricator.services.mozilla.com/D237045, to allow Google Docs to use execCommand() without triggering a warning in Firefox.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/57912b1d826e
https://hg.mozilla.org/integration/autoland/rev/eda69cca83c3
Expose execCommand("paste") with a pop-up menu to web content; r=smaug,masayuki

Comment 8

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56711 for changes under testing/web-platform/tests

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/bd4fd9849575
https://hg.mozilla.org/integration/autoland/rev/defc3b0e4a6c
Revert "Bug 1998195 - Expose execCommand("paste") with a pop-up menu to web content; r=smaug,masayuki" for causing build bustage @nsGlobalWindowCommands.cpp

Comment 10

[pstanciu]

Backed out for causing build bustage @nsGlobalWindowCommands.cpp

• Backout link
• Push with failures
• Failure Log build @nsGlobalWindowCommands.cpp
• Failure Log tv @exec-command-with-text-editor.tentative.html

Comment 11

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=168693

Comment 12

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dc97c6365354
https://hg.mozilla.org/integration/autoland/rev/9e767166ed95
Expose execCommand("paste") with a pop-up menu to web content; r=smaug,masayuki

Comment 14

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/56721 for changes under testing/web-platform/tests

Comment 15

[amarc]

https://hg.mozilla.org/mozilla-central/rev/9e767166ed95

Comment 16

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 17

[Hamish Willee]

FF148 MDN Docs work for this can be tracked in https://github.com/mdn/content/issues/42747

I have read the comment above https://bugzilla.mozilla.org/show_bug.cgi?id=1998195#c2. My understanding is as below - can you confirm the questions/open bits?

For web content:

1. Prior to this change, if you called Document.execCommand() with the "paste" option, the method would simply return false (i.e. pasting into content was not allowed)
2. After this change, if you call the option with content copied from the same-origin it will succeed. If you call the option with content copied cross-origin it will pop up a little "Paste" UI that you need to click to paste. If you don't click the paste the method will return false and copying will not happen.

For Web Extensions:
3. After this change, if you call the method in a web extension that has the clipboardRead permission the paste will succeed both for same-origin and cross-origin content.
4. If you call this for paste without that permission presumably same origin would succeed but you'd get the same prompt in extension as for ordinary content?
5. What about before the change - did the command just not work?

NOTE however for ^^^ - from https://github.com/mdn/content/pull/42263#pullrequestreview-3708855702 it looks like FF and Safari don't support those permissions so presumably the read/write just always succeeds?

Perhaps we should simply note that the copy and paste are implemented with the clipboard API on FF and Safari and will behave in the same way a paste using that API?

6. The [spec (https://w3c.github.io/editing/docs/execCommand/#the-paste-command) indicates

   • that the method should throw a SecurityError if it isn't allowed to read the content of the clipboard. Is that supported?
   • transient activation is require - is that also required here?

7. Can you user permissions policy (or feature-policY) on a cross-origin page to allow it to copy cross origin content without the prompt

8. Is there any particular release note you would like for this in MDN?

Comment 18

[Edgar Chen [:edgar]]

Please see my inline comments. Thanks!

(In reply to Hamish Willee from comment #17)

For web content:

1. Prior to this change, if you called Document.execCommand() with the "paste" option, the method would simply return false (i.e. pasting into content was not allowed)
2. After this change, if you call the option with content copied from the same-origin it will succeed. If you call the option with content copied cross-origin it will pop up a little "Paste" UI that you need to click to paste. If you don't click the paste the method will return false and copying will not happen.

Exactly! This is the same security model as clipboard.read().

For Web Extensions:
3. After this change, if you call the method in a web extension that has the clipboardRead permission the paste will succeed both for same-origin and cross-origin content.
4. If you call this for paste without that permission presumably same origin would succeed but you'd get the same prompt in extension as for ordinary content?
5. What about before the change - did the command just not work?

Before this change, WebExtensions were not allowed to use this method (return false) without the clipboardRead permission.

NOTE however for ^^^ - from https://github.com/mdn/content/pull/42263#pullrequestreview-3708855702 it looks like FF and Safari don't support those permissions so presumably the read/write just always succeeds?

We do support clipboardRead permission in WebExtension, see https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#clipboardread.

Perhaps we should simply note that the copy and paste are implemented with the clipboard API on FF and Safari and will behave in the same way a paste using that API?

For web content, yes. I don't know about Safari extension.

6. The [spec (https://w3c.github.io/editing/docs/execCommand/#the-paste-command) indicates
   • that the method should throw a SecurityError if it isn't allowed to read the content of the clipboard. Is that supported?

No, we don't throw a SecurityError, but return false instead. I believe other browser behave the same.

• transient activation is require - is that also required here?

Yes, the transient activation is require, except WebExtension with clipboardRead permission, it can access without transient activation.

7. Can you user permissions policy (or feature-policY) on a cross-origin page to allow it to copy cross origin content without the prompt

No, for web content there is no way to suppress the prompt when copy cross-origin content.

8. Is there any particular release note you would like for this in MDN?

No, I think everything is covered. Thanks!