<textarea>.focus() and .select() do not work in background pages

RESOLVED FIXED

Status

defect
P3
normal
RESOLVED FIXED
3 years ago
5 months ago

People

(Reporter: chef, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug)

49 Branch
x86_64
Windows 10
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [clipboard] triaged)

Attachments

(1 attachment)

4.78 KB, application/octet-stream
Details
Reporter

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36

Steps to reproduce:

in background page:

(function(doc) {

   console.log('one');
   console.log(doc.exeCommand('copy'));
   console.log('two');

}).call(this, document);



Actual results:

Only "one" is logged.
No error is logged.
Reporter

Updated

3 years ago
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
This works as expected for me:

try {
  document.execCommand("copy");
} catch (e) {
  console.error(e);
}

Error: document.execCommand('cut'/'copy') was denied because it was not called from inside a short running user-generated event handler.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1197451
Reporter

Comment 2

3 years ago
For some reason I'm not seeing unhandled exceptions in the console at all in Nightly 49.0a1.

In addition, it's not currently possible to step through the code because the Debugger is broken (eg, breakpoints are ignored or wildly unpredictable, resume doesn't do anything, step in/out lands you in random places)

These issues have led to confusion about observed behavior, so I apologize if I haven't effectively communicated the essence of the problem I'm experiencing with execCommand('copy).

I'm attaching a sample extension (clipboardTest.xpi) that illustrates a problem where execCommand('copy') does NOT throw an exception and returns true, yet does not actually copy anything to the clipboard. To test: click on browser_action to open the popup. Click "Copy". Note that the clipboard does not contain the contents "COPY TEXT" as expected.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Reporter

Comment 3

3 years ago
Posted file clipboardTest.xpi
Reporter

Updated

3 years ago
Summary: call to doc.exeCommand('copy') ends execution without error → exeCommand('copy') returns true but does not copy to clipboard
Reporter

Updated

3 years ago
Summary: exeCommand('copy') returns true but does not copy to clipboard → execCommand('copy') returns true but does not copy to clipboard and oncopy does not fire

Comment 4

3 years ago
Does your add-on work in Chrome? In this case you are grabbing the background page window and attempting calling the API there. The correct way to do this is message passing as LA-MJ outlines in bug 1197451.

Just a simple check shows that execCommand("copy") returns true in a popup. Ideally it should return false to say its not available. This might get fixed in bug 1197451, but since its a slightly different problem, it probably makes sense to leave it open.
Priority: -- → P4
Whiteboard: triaged
Reporter

Comment 5

3 years ago
Yes the extension works in Chrome.

The sample extension you mention from bug 1197451 has to use message passing because a content script doesn't have access to the browser.extension.getBackgroundPage() API.

Calling a background page function directly from a popup or an extension tab is a common pattern (they all run in the same thread). Unless I'm mistaken, that's the point of the getBackgroundPage() API.

It's not clear whether clipboard write failure in this particular case is a bug vs intentional behavior. If it's intentional, I propose that this be articulated explicitly and opened up for discussion.
The problem there is with your attempt to set the selection, not with the copy command. `.select()` only works on elements that are focused, which your textarea is not.
Reporter

Comment 7

3 years ago
Thanks Kris, that provides a lot of insight.

I ran some tests to further clarify the core issue. Here's what I confirmed:

- In FF and Chrome, .select() implicitly focuses a focusable element. This implies that .select() alone is normally sufficient to prime an execCommand('copy') call.

- FF does not seem to allow focus on elements on the background page (tried with .focus() and .select()). This is the fundamental issue. Chrome, on the other hand, does allow this. This may be something worth pursuing parity on. If you want me to create a separate ticket for this, let me know. I don't currently have a use case for it though as I can easily work around the FF limitation by passing a textarea element in the popup document to my execCommand('copy') wrapper on the bg page.

As far as I'm concerned we can close this particular bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: P4 → --
Summary: execCommand('copy') returns true but does not copy to clipboard and oncopy does not fire → <textarea>.focus() and .select() do not work in background pages
Whiteboard: triaged
See Also: → 1197451
Assignee: nobody → rob
Depends on: 1274775

Comment 8

3 years ago
P1 because impacting top tier API
Priority: -- → P1
Whiteboard: [clipboard] triaged

Comment 9

3 years ago
Rob, after you took this, it got marked as a P1. I'm wondering if this is something you are planning on working on in the next while or maybe we should re-assign?

Comment 10

3 years ago
I haven't planned to work on it, so it is up for grabs.
Assignee: rob → nobody
While testing for bug 1340556, I discovered this does work with OOP extensions, so if nobody gets to fixing it before bug 1190679, this can just enable the test.
Depends on: webext-oop
We should probably enable the test in OOP mode, then.
Do we have a clean way to do this, other than separating the test into it's own file?  I believe every other way of skipping tests is frowned upon..

Comment 14

2 years ago
Dropping priority, because WebExtensions will have a dedicated clipboard API as part of bug 1344410.

And with out-of-process WebExtensions copying with document.execCommand works in the background page, so if that becomes the only supported mode, then this bug can be closed anyway.
Priority: P1 → P3

Comment 15

2 years ago
I would politely request holding the priority until bug 1344410 is indeed done. Thanks.
Flags: needinfo?(rob)

Comment 16

2 years ago
The cause for this bug is unknown and likely not going to be found anytime soon.

On the other hand, bug 1344410 is relatively easy to implement (and I will write an implementation after I submit patches for the contextMenus API).
Flags: needinfo?(rob)

Comment 17

2 years ago
This seems to work now.

The following code works now in background page:
>  let input = document.createElement("textarea");
>  document.body.append(input);
>  input.value = info.linkText;
>  input.select();
>  document.execCommand("copy");

Can this bug now be resolved as fixed?
Flags: needinfo?(rob)

Comment 18

2 years ago
What OS were you testing on kernp25?

Comment 19

2 years ago
(In reply to kernp25 from comment #17)
> This seems to work now.
> 
> The following code works now in background page:
> >  let input = document.createElement("textarea");
> >  document.body.append(input);
> >  input.value = info.linkText;
> >  input.select();
> >  document.execCommand("copy");
> 
> Can this bug now be resolved as fixed?

If you visit about:config and look for the value of extensions.webextensions.remote , is it set to true (it probably is if you use Windows, since Firefox 56 - per bug 1357486).
If it is set to false, and your code still works, then the bug has been fixed.
But I think that it is more likely that out-of-process WebExtensions is turned on.

Comment 20

2 years ago
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0

Comment 21

2 years ago
Yes! The pref "extensions.webextensions.remote" is true

Comment 22

2 years ago
Then the bug has not been fixed. Somehow .focus() and .select() work in background pages when out-of-process WebExtensions are enabled, but it's not clear why. OOP WebExtensions are not yet enabled on Linux (bug 1357487) and macOS (bug 1385403). Firefox on Android is single-process and will likely not have out-of-process extensions (though I have never tested whether Android is also affected by this bug. Maybe it is, maybe not).
Flags: needinfo?(rob)
Depends on: 1357487

Updated

11 months ago
Product: Toolkit → WebExtensions

Updated

10 months ago
Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958
Component: Untriaged → General
Do we need this still, now that we have the Clipboard Web API?
Flags: needinfo?(rob)

Comment 25

5 months ago
This is fixed, because out-of-process WebExtensions is enabled everywhere (with the last being Firefox on Linux - bug 1357487).
Status: NEW → RESOLVED
Last Resolved: 3 years ago5 months ago
Flags: needinfo?(rob)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.