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

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P3)

Description

[Hans Meyer]

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.

Comment 1

[Kris Maglione [:kmag]]

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.

Comment 2

[Hans Meyer]

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.

Comment 3

[Hans Meyer]

Attachment: clipboardTest.xpi

Comment 4

[Andy McKay]

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.

Comment 5

[Hans Meyer]

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.

Comment 6

[Kris Maglione [:kmag]]

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.

Comment 7

[Hans Meyer]

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.

Comment 8

[:shell escalante]

P1 because impacting top tier API

Comment 9

[Andy McKay]

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

[Rob Wu [:robwu]]

I haven't planned to work on it, so it is up for grabs.

Comment 11

[Tomislav Jovanovic :zombie]

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.

Comment 12

[Kris Maglione [:kmag]]

We should probably enable the test in OOP mode, then.

Comment 13

[Tomislav Jovanovic :zombie]

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

[Rob Wu [:robwu]]

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.

Comment 15

[Worcester12345]

I would politely request holding the priority until bug 1344410 is indeed done. Thanks.

Comment 16

[Rob Wu [:robwu]]

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).

Comment 17

[kernp25]

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?

Comment 18

[Andy McKay]

What OS were you testing on kernp25?

Comment 19

[Rob Wu [:robwu]]

(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

[kernp25]

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

Comment 21

[kernp25]

Yes! The pref "extensions.webextensions.remote" is true

Comment 22

[Rob Wu [:robwu]]

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).

Comment 23

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958

Comment 24

[Geoffrey De Belie (Smile4ever)]

Do we need this still, now that we have the Clipboard Web API?

Comment 25

[Rob Wu [:robwu]]

This is fixed, because out-of-process WebExtensions is enabled everywhere (with the last being Firefox on Linux - bug 1357487).