Closed Bug 1272869 Opened 4 years ago Closed 2 years ago

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

Categories

(WebExtensions :: General, defect, P3)

49 Branch
x86_64
Windows 10
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: chef, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [clipboard] triaged)

Attachments

(1 file)

4.78 KB, application/octet-stream
Details
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.
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
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1197451
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 → ---
Attached file clipboardTest.xpi
Summary: call to doc.exeCommand('copy') ends execution without error → exeCommand('copy') returns true but does not copy to clipboard
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
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
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.
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
P1 because impacting top tier API
Priority: -- → P1
Whiteboard: [clipboard] triaged
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?
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..
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
I would politely request holding the priority until bug 1344410 is indeed done. Thanks.
Flags: needinfo?(rob)
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)
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)
What OS were you testing on kernp25?
(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.
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:57.0) Gecko/20100101 Firefox/57.0
Yes! The pref "extensions.webextensions.remote" is true
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
Product: Toolkit → WebExtensions
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)
This is fixed, because out-of-process WebExtensions is enabled everywhere (with the last being Firefox on Linux - bug 1357487).
Status: NEW → RESOLVED
Closed: 4 years ago2 years ago
Flags: needinfo?(rob)
Resolution: --- → FIXED
See Also: → 1603985
You need to log in before you can comment on or make changes to this bug.