1634273 - execCommand('copy') denied despite being called in keydown event handler (non-printable characters)

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect)

Description

[moestl.robert]

Attachment: markdown-link-extension_v1.3.zip

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

It is an issue that occurs when I use the web extension called "Markdown Link" which I developed. It is available at https://addons.mozilla.org/en-US/firefox/addon/markdown-link/.

The extension uses execCommand('copy') to copy the site's title and URL as a Markdown link when the user hits Alt+Insert.

Steps to reproduce:

• Install the extension from the link above or install it temporarily from the extension files I've attached in this report.
• Load an arbitrary website.
• Don't interact with the site (e.g. not clicking)
• Hit Alt+Insert on your keyboard

Actual results:

The error document.execCommand(‘cut’/‘copy’) was denied because it was not called from inside a short running user-generated event handler. is raised in the console. As a result the Markdown Link is not copied into the clipboard.

Expected results:

The error should not have been raised because execCommand('copy') has clearly been called within a user-generated event handler.

The funny thing is, when you click once somewhere on the page and then you hit Alt-Insert, then the command works and is executed properly.

Comment 1

[BugBot [:suhaib / :marco]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Rob Wu [:robwu]]

Apparently keydown events with modifiers and non-printable characters are not counted as a valid user activation. This is not documented (not in document.execCommand article on MDN, nor as part of the spec.

Edgar, is this an intentional limitation?

---

To extension authors running into this problem: Add the clipboardWrite permission to manifest.json to be able to copy to the clipboard without the normal user gesture requirements.

And a bit of advice for this specific extension: You don't need a content script for your functionality. Your extension would be much more efficient and reliable if you:

1. Use the commands.onCommand API to handle the shortcut, from the background page.
2. Use the tabs API (with the tabs permission) to query the current title and URL.
3. Use the execCommand API (with the clipboardWrite permission) to copy the text to the clipboard, from the background page.

Comment 3

[moestl.robert]

Thanks for the quick reply and thanks for the recommendations. I'll give them a try!

Comment 4

[Edgar Chen [:edgar]]

(In reply to Rob Wu [:robwu] from comment #2)

Apparently keydown events with modifiers and non-printable characters are not counted as a valid user activation. This is not documented (not in document.execCommand article on MDN, nor as part of the spec.

Edgar, is this an intentional limitation?

Yes, it is intentional, and the event set is inconsistent across major browsers, https://github.com/whatwg/html/issues/3849 tries to address it at spec level.

Comment 5

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (non,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 6

[BugBot [:suhaib / :marco]]

The priority flag is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 7

[Rob Wu [:robwu]]

Although extensions have an extension-specific permission to work around the issue, the core of the issue is not specific to extensions. If the issue is addressed for regular web pages, this bug would automatically be resolved. So I'm moving this out of extensions, over to DOM.

And I've added dev-doc-needed to request this restriction to be documented (comment 2, comment 4).

Comment 8

[anton.kosyakov]

We are getting the similar error in Theia although the even handler is synchronous and runs in less than 0.5s, see https://github.com/eclipse-theia/theia/pull/7851#issuecomment-631533417

It seems to start happening after https://github.com/mozilla/gecko-dev/commit/ff965689f51f9c26a3a25ec248034c41ff1eef19

Comment 9

[Emilio Cobos Álvarez [:emilio]]

Edgar, just so the comment above doesn't fall out of your radar.

Comment 10

[Edgar Chen [:edgar]]

(In reply to anton.kosyakov from comment #8)

We are getting the similar error in Theia although the even handler is synchronous and runs in less than 0.5s, see https://github.com/eclipse-theia/theia/pull/7851#issuecomment-631533417

Filed a separated bug for this, bug 1640883.

Comment 11

[[:jaborandi]]

So, if i understand it correctly, execCommand('copy') does NOT work if the page is not "activated" (per UserActivation) - i.e. browser assumes that user has not initiated interaction with the page.

Then, i think, the bug title / description have to be updated: it's not that copy to clipboard doesn't work for key combinations - it does. It just doesn't work UNTIL the page is activated, and it is not activated by pressing key combinations - only by pressing regular keys alone, without modifiers.

This behavior is very strange and impossible for me to explain - why opening a web page and hitting key "A", for example, does activate it (even if nothing gets typed anywhere) , but opening the same page and hitting "Ctrl+A" - does NOT.
Obviously a rich web application can and do have all kinds of key combinations doing all possible things, including copying something to clipboard. A good application also allows users to customized those key combinations to whatever user prefers - so, basically, any combination may need to copy to clipboard.

And what this bug entails for such applications is that if user has opened it and STARTS interaction with trying to use such function - it will not work. While it works if he did something else, that "counts" as activation, before.
This is quite an inexplicable inconsistency.

I understand, that this is probably not the place for discussing what should count as UserActivation - there's a https://github.com/whatwg/html/issues/3849
I probably should try and ask this question there

But so far just wanted to make the point that the bug doesn't clearly describe the problem.

Thank you

Comment 12

[[:jaborandi]]

Edgar,
i read https://github.com/whatwg/html/issues/3849 and it never mentions any intention to exclude all non-printable key combinations from activating the page.
only combinations reserved by the browser - i.e. ctrl+T
right now the behavior is irrational - FF "blocks" hundreds of combinations it doesn't even know about let alone uses, from activating the page
even arrow keys are blocked! (which leads to an utterly confusing situation - user comes to a page, diligently navigates using up/down keys in whatever interface is there - yet page is not active, the user interaction has not been initiated in FF view)

also, even apart from that, if the reason execCommand('copy') is blocked is due to page not having been activated, then ideally this should be explicitly stated in the error message: "execCommand("copy") is blocked, because page has not been activated by user interaction" (the current error message, beside not being informative, isn't even technically correct)