Closed Bug 1324255 Opened 7 years ago Closed 6 years ago

Opening a popup does not focus the browser frame

Categories

(WebExtensions :: Frontend, defect, P1)

defect

Tracking

(firefox58 wontfix, firefox59 wontfix, firefox60 verified, firefox61 verified)

VERIFIED FIXED
mozilla60
Tracking Status
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- verified
firefox61 --- verified

People

(Reporter: kumar, Assigned: mixedpuppy)

References

(Depends on 1 open bug)

Details

(Whiteboard: triaged)

Attachments

(6 files, 4 obsolete files)

To reproduce:
- Create an extension with a browser action that has a popup with a page that listens for key events, like:

<!DOCTYPE html>
<html>
  <body>
    Check the console
    <script type="text/javascript">

document.addEventListener('keyup', (event) => {
  console.log('got keyup', event, 'keyName', event.key);
}, false);

    </script>
  </body>
</html>

- install the extension in Firefox Nightly
- open the Browser Console
- click the browser action to show the popup
- start typing any key

Expected: The keyup event should trigger console messages

What actually happens: There are no console messages. However, if you click anywhere in the popup window with the mouse and then type keys, you will see console messages.

It seems like the popup window isn't in focus (not sure if that's the right word) when you click the browser action button but I think it should be. It works as expected on Chrome.
Here is an extension to reproduce the bug.

You'll see a workaround in popup.js (commented out) that focuses the body. I don't think this should be required though.
Priority: -- → P3
Whiteboard: triaged
Huh. The workaround *only* works in Firefox release 50.1.0, but not in Nightly 53.0a1 (2016-12-18).

Thus, it looks like there is a regression somewhere (maybe). It would be great to fix this before it gets released.

If it doesn't get fixed in time, can anyone suggest another work around?
ok, so this is definitely some kind of timing issue. Focusing the body after a delay is now working (as a hacky workaround) to listen for key events when the popup opens:

setTimeout(() => {
  document.querySelector('body').focus();
}, 100);
Also, the regression I mentioned in comment 2 is also present in FDE 52.0a2 (2016-12-19)
Summary: Opening a browser action popup does not focus it → Opening a popup does not focus the browser frame
Any workarounds? Delay does not work for me in 55.01.

Any plans to make this work at least in 57? (I mean, how hard can this be?)

I can imagine hundreds of add-ons that needs to be focused when pop-up is opened - for typing / pasting / navigation / key shortcuts...
The delay workaround seems to be working for me in 57.0a1 (2017-08-15)
I'm sorry, I really does work :) Thank you!
I must have done something wrong with my initial attempts...
Attached image FocusBug.gif
Animation showing click into pop-up then body selected then input selected using JS delays.  Nothing gets selected if body of pop-up is not clicked.  (FF56.0b6-x64)
@Paul try to use two delayed focus calls - one in 100ms and second in 150ms.
First put into 'DOMContentLoaded' event handler, second in window 'load' event handler.
This setup seems to work (in 55.0.3).
Same issue here, the workaround doesn't work for me, not even when I use two delayed calls. Tested with today's beta and nightly under Linux.
I have this same problem in Nightly 57.0a1 (2017-09-02) (64-bit). The workaround doesn't seem to work
Yes I can confirm both Beta (56.0b8) and Nightly channels are now affected with this bug.
This is up to 6 dupes. We should probably prioritize it higher.
Priority: P3 → P1
I can reproduce this in Nightly 58 (I did not try the workaround). I agree that this is a high priority to fix. Many, many extensions are browser_action popups.
Assignee: nobody → mixedpuppy
just some notes.

My specific test on this is using an input element with autofocus.  The focusedElement is correct for the document, but focus is not placed into the browser for this.  I've dug around trying to make this work similar to the workaround described earlier, but it only works occasionally.
Comment on attachment 8919493 [details]
Bug 1324255 make webextension panels focused when opened,

WIP patch.  Basically, I'm unable to force a focus prior to transitionend on the panel.  I'm also unable to get the documents focusedElement reliably except within the content script, as well, I cannot seem to make this work from within ExtensionPopup.jsm.
Attachment #8919493 - Flags: feedback?(kmaglione+bmo)
Comment on attachment 8919493 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/190332/#review196912

::: browser/components/extensions/ExtensionPopups.jsm:84
(Diff revision 1)
>        this._resolveContentReady = resolve;
>      });
>  
>      this.viewNode.addEventListener(this.DESTROY_EVENT, this);
> +    // XXX this is what I'd like to use, but this event is never received here.
> +    this.panel.addEventListener("transitionend", this, true);

That's because we initially create a throw-away popup that we use to pre-load the <browser> before it's ready to be shown.
Attachment #8919493 - Flags: feedback?(kmaglione+bmo) → feedback+
Flags: needinfo?(gijskruitbosch+bugs)
Did you intend to ask a specific question? I guess based on our previous IRC discussion that you needinfo'ing me means the ViewShown listener wasn't sufficient here for some reason? Can you elaborate on this and/or anything else you have tried / want to ask me about? As it is I'm unsure how to respond to the needinfo, sorry!
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mixedpuppy)
(In reply to :Gijs (slow, PTO recovery mode) from comment #28)
> Did you intend to ask a specific question?

Sorry, it was more to remind me to chat with you.  

ViewShown wont work because the browserAction does some swapping of the browser having to do with preloading, even then it seems to be fired prior to transitionend.  For whatever reason, seems I cannot focus until transitionend.  I also am not receiving ViewShown on PageActions.
Flags: needinfo?(mixedpuppy)
Is there a way to avoid this problem in Firefox 57?
It is very troubling when creating WebExntensions version.
Gijs, lets chat when you got time.  So far the only thing I see working reliably is the transitionend, but I haven't been entirely comfortable with that.
Flags: needinfo?(gijskruitbosch+bugs)
AFAICT this works:

https://pastebin.mozilla.org/9072863

I haven't put in the automated test, or tested with page actions, and I've only checked on macOS for now. It'd be good to check especially Windows because focus in remote child windows might behave differently. It'd probably be a good idea to get someone like Neil Deakin to review this bit of the patch. I used focusManager.focusedWindow because element.focus() shows an ugly focus rectangle. Shane, can you verify this works? :-)
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mixedpuppy)
Err, without the useless lazy import: https://pastebin.mozilla.org/9072864
(In reply to :Gijs (slow, PTO recovery mode) from comment #33)
> Err, without the useless lazy import: https://pastebin.mozilla.org/9072864

Annnnd it seems we don't actually need the ViewShown listener. Also, the above doesn't help with page actions. I don't have an add-on to test that with, but I *think* this should work: https://pastebin.mozilla.org/9072867 .
That does work most of the time.  I'll upload a test addon I've been using.  

I'm able to intermittently see that autofocus doesn't work.  It is most apparent when switching directly between the page action and the browser action, but that is not required.  opening/closing a bunch of times resulted in a failure to get focus.
Flags: needinfo?(mixedpuppy)
Attached file datalist.xpi
This is an addon I test a number of ui issues with.  The input has autofocus on it, and it will be outlined in red when it is actually focused.  Upon install, the sidebar will open, you should see the input box is red outlined.  Open the browser action, it should focus, close, the sidebar should get it back.

The easy failure I see is when directly switching between the page and browser action.  The harder failure to reproduce is just opening/closing one or the other, once in a blue moon focus fails.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Shane Caraveo (:mixedpuppy) from comment #36)
> Created attachment 8928766 [details]
> datalist.xpi
> 
> This is an addon I test a number of ui issues with.  The input has autofocus
> on it, and it will be outlined in red when it is actually focused.  Upon
> install, the sidebar will open, you should see the input box is red
> outlined.  Open the browser action, it should focus, close, the sidebar
> should get it back.
> 
> The easy failure I see is when directly switching between the page and
> browser action.  The harder failure to reproduce is just opening/closing one
> or the other, once in a blue moon focus fails.

The page action is always disabled for me, so I can't reproduce this, sorry. Aggro-clicking the browser action button repeatedly also hasn't allowed me to reproduce this yet. :-(

I can look at this more on Monday. We could potentially land the patch as-is and iterate, if you'd be comfortable with that? Alternatively, maybe Kris has ideas about what we're missing here. That or adding lots of logging to the focus manager to see what's going on, I guess...
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mixedpuppy)
What is the timeline on this bug?  We have a couple bugs we are trying to fix for Containers, and are wondering whether to assume that the tab is required, or assume it isn't.  Thanks!

https://github.com/mozilla/multi-account-containers/issues/941

https://github.com/mozilla/multi-account-containers/pull/992
Gijs, the pastebins expired, do you have that patch?
Flags: needinfo?(mixedpuppy) → needinfo?(gijskruitbosch+bugs)
(In reply to Shane Caraveo (:mixedpuppy) from comment #39)
> Gijs, the pastebins expired, do you have that patch?

hg hidden nodes had it, I pruned it ages ago. Took me a while to find though... Thank Mossop for the tip of only searching hidden nodes!
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs from comment #40)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #39)
> > Gijs, the pastebins expired, do you have that patch?
> 
> hg hidden nodes had it, I pruned it ages ago. Took me a while to find
> though... Thank Mossop for the tip of only searching hidden nodes!

Uh, and I emailed them to you, cba trying to attach all 3 to bugzilla. I should probably take Mossop's other tip and go to sleep.
Autofocus on text field will working if set extensions.webextensions.remote to false in about:config.
https://thumbs.gfycat.com/DeficientIdolizedKittiwake-size_restricted.gif
However doing to will lead to Bug 1425829 (blank popup window until do a right-click)
Sorry if this is the wrong place to ask about this, but: is there a workaround (partial or otherwise) that extension authors can use right now?  I'm not able to get Kumar's setTimeout workaround to focus a select input in an extension popup in Firefox 58.0b16.
Looking back through the comments again and installing Shane's extension, I think I'm seeing different behaviour than Gijs and Shane.

On Ubuntu 16.04, 58.0b16 with datalist.xpi I *never* see the input focused in the popup.  The sidebar that opens on install is focused (I haven't actually figured out yet how to show that sidebar a second time...).

As a total C++ amateur who only ever uses it occasionally when fixing bugs, if anybody has advice where to look to start to debug that I'd appreciate it...
Comment on attachment 8919493 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/190332/#review221232

rs=me; haven't checked if this works, but very happy with the automated tests. Thanks!
Attachment #8919493 - Flags: review?(gijskruitbosch+bugs) → review+
Comment on attachment 8919493 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/190332/#review221770

The patch and the new test cases looks good to me, I've added some comments related a few proposed tweaks and some nits, but my main concern is the timeout failure that "./mach --verify" was able to trigger locally (I've triggered a try build with TV from mozreview, let's see if it is reproducible also on try).

In the meantime I'm going to r+ it, with green try, and double-checking if the TV failure is a reproducible issue
(I run these tests on a linux64 laptop on an uncommon windows manager, on a fluxbox wm running inside Xephyr, and the windows manager may affect this kind of issues).

::: browser/components/extensions/ExtensionPopups.jsm:83
(Diff revision 3)
>      this.contentReady = new Promise(resolve => {
>        this._resolveContentReady = resolve;
>      });
>  
>      this.viewNode.addEventListener(this.DESTROY_EVENT, this);
> +    this.panel.addEventListener("popuppositioned", this, true);

I'm wondering if we could subscribe and unsubscribe the event listener from the same place, which seems to require to do it in the subclasses because of the differences between the pageAction popup and the browserAction popup.

e.g. subscribing the "popuppositioned" listener in the constructor (right after having called `super(...)`) for the PanelPopup and in the attach method for the ViewPopup, and then unsubscribe the event in ViewPopup and PanelPopup destroy method (right before calling `return super.destroy().then(...);`)

How that sounds to you?

::: browser/components/extensions/ExtensionPopups.jsm:219
(Diff revision 3)
>          if (!this.destroyed) {
>            this.destroy();
>          }
>          break;
> +      case "popuppositioned":
> +        this.browser.messageManager.sendAsyncMessage("Extension:GrabFocus", {});

Nit, I'm wondering if we should also check that `this.destroyed` is not true before trying to send the "Extension:GrabFocus" message, just in case the popuppositioned event is received right after the popup being closed (anyway, it should be a big deal, because we are inside the event handler and in the worst case an exception is going to be raised and the message is never going to not be sent, but besides that it should not break anything).

::: browser/components/extensions/ExtensionPopups.jsm:219
(Diff revision 3)
>          if (!this.destroyed) {
>            this.destroy();
>          }
>          break;
> +      case "popuppositioned":
> +        this.browser.messageManager.sendAsyncMessage("Extension:GrabFocus", {});

I tried to run the tests locally using "./mach mochitest --verify ...", because I wasn't sure that it is actually 100% sure that when we have received the popuppositioned event, the XUL browser has already completed to load the popup url, and it fails after a number of the --verify automated runs.

The tests seems to fail if the popup is being loaded after the "Extension:GrabFocus" has been sent (which seems to be a scenario which --verify is able to trigger).

I'm wondering if something like the following may help:

```
case "popuppositioned":
  !this.destroyed && this.browserLoaded.then(() => {
    if (this.destroyed) {
      return;
    }
             
           
    this.browser.messageManager.sendAsyncMessage("Extension:GrabFocus", {});
  });
  break;
```

When I briefly tried the above change locally (on linux64), "./mach mochitest --verify" has been able to complete successfully once, but it was still able to trigger the timeout from time to time.

::: browser/components/extensions/test/browser/browser_ext_pageAction_popup.js:244
(Diff revision 3)
> +  let extension = ExtensionTestUtils.loadExtension({
> +    manifest: {
> +      "page_action": {"default_popup": "popup.html"},
> +    },
> +    background() {
> +      browser.tabs.onActivated.addListener(details => {

Nit, this could also be written as an async function

```
browser.tabs.onActivated.addListener(async (details) => {
  await browser.pageAction.show(...);
  browser.test.sendMessage("shown");
});
```
Attachment #8919493 - Flags: review?(lgreco) → review+
I'm dropping the input autofocus part of the tests since a) I haven't figured out how to make debug happy with them, and b) it's not the important part of this, which is simply getting focus into the extension popup windows.  From that point, extensions can actually handle the use cases they are looking for.
Reverting the suggestion from comment 48 about where I add popuppositioned listeners got this passing the TV tests on windows.  Don't know why for sure, but it did.
Flags: needinfo?(lgreco)
Comment on attachment 8919493 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/190332/#review224254

::: browser/components/extensions/ExtensionPopups.jsm:83
(Diff revision 6)
>      this.contentReady = new Promise(resolve => {
>        this._resolveContentReady = resolve;
>      });
>  
>      this.viewNode.addEventListener(this.DESTROY_EVENT, this);
> +    this.panel.addEventListener("popuppositioned", this, true);

It looks that we only want to send a "Extension:GrabFocus" message only once, can we use onetime: true when we subscribe this "popuppositioned" events?

::: browser/components/extensions/ExtensionPopups.jsm:220
(Diff revision 6)
>            this.destroy();
>          }
>          break;
> +      case "popuppositioned":
> +        if (!this.destroyed) {
> +          this.browserLoaded.then(() => {

It looks that waiting the `this.browserLoaded` promise to be resolved is currently making some of the existent tests to fail, e.g.:

- https://treeherder.mozilla.org/#/jobs?repo=try&revision=2d9388393da5&selectedJob=160855085

It seems that the easiest fix is to revert this to something like:

```
if (this.destroyed) {
  return;
}

this.browser.messageManager.sendAsyncMessage("Extension:GrabFocus", {});
```

::: browser/components/extensions/ExtensionPopups.jsm:455
(Diff revision 6)
>    async attach(viewNode) {
>      this.viewNode = viewNode;
>      this.viewNode.addEventListener(this.DESTROY_EVENT, this);
>      this.viewNode.setAttribute("closemenu", "none");
>  
> +    this.panel.addEventListener("popuppositioned", this, true);

When we set the new viewNode at line 451 we are basically switching from the `tempPanel` (the one that is also set to `this.tempPanel` at line 434, which is never going to be shown) to the panel attached, can we at least remove the event listener that the base class constructor has subscribed on the `tempPanel`?

(In a follow up it would be nice to refactor this class, it would be nice if instead of re-assigning directly the `viewNode` property defined by the base class constructor here we could make the superclass aware that we are changing the panel, so that the base class may handle the popuppositioned event subscribing/unsubscribing by itself)
Comment on attachment 8919493 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/190332/#review224264

::: browser/components/extensions/ExtensionPopups.jsm:130
(Diff revision 6)
>  
>        let {panel} = this;
>        if (panel) {
>          panel.style.removeProperty("--arrowpanel-background");
>          panel.removeAttribute("remote");
> +        panel.removeEventListener("popuppositioned", this, true);

Given that we subscribe the event listener even if the panel is never being ready, how about moving this `panel.removeEventListener` near line 106? (basically out of this.browserReady.then).
Flags: needinfo?(lgreco)
See Also: → 1435687
browser_ext_currentWindow.js was opening popups in background windows.  Once we add the focus on opening of our popups, it focuses the window they are in, bringing it forward, which in turn causes the popup to close (and subsequent tests to fail).  It is actually unrealistic to have a popup open in anything other than the top window, so I'm changing the test.
Attachment #8919493 - Attachment is obsolete: true
Attachment #8950770 - Attachment is obsolete: true
Attachment #8950770 - Flags: review?(lgreco)
Attachment #8950770 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 8950794 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/220030/#review226126
Attachment #8950794 - Flags: review?(gijskruitbosch+bugs) → review+
Comment on attachment 8950794 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/220030/#review226132

Err, I should actually look at this. Sorry.
Attachment #8950794 - Flags: review+ → review?(gijskruitbosch+bugs)
Attachment #8950794 - Attachment is obsolete: true
Attachment #8950794 - Flags: review?(lgreco)
Attachment #8950794 - Flags: review?(gijskruitbosch+bugs)
Comment on attachment 8950794 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/220030/#review226268

r=me on the code, but try shows  browser/components/extensions/test/browser/test-oop-extensions/browser_ext_browserAction_popup.js is failing because the popup gets destroyed, or something. Maybe you need the destroyed check that was there before, even if not waiting for `this.browserLoaded` ?
Attachment #8950794 - Flags: review+
Comment on attachment 8951035 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/220296/#review226270

Again, code looks OK, but this time the focus test is timing out in TV mode...
Attachment #8951035 - Flags: review?(gijskruitbosch+bugs) → review+
Attachment #8951035 - Attachment is obsolete: true
Attachment #8951035 - Flags: review?(lgreco)
Ok, I think I got the tests passing (one more try running on rb).  

I don't know why pushing to rb has started to obsolete prior patches, I'll try to dig into why that is happening tomorrow.
Comment on attachment 8951099 [details]
Bug 1324255 make webextension panels focused when opened,

https://reviewboard.mozilla.org/r/220358/#review226424

LGTM. Might just want to land on inbound and set the review flags in the commit message yourself...
Attachment #8951099 - Flags: review?(gijskruitbosch+bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/54679984f078
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
(In reply to Narcis Beleuzu [:NarcisB] from comment #71)
> https://hg.mozilla.org/mozilla-central/rev/54679984f078

I tested the latest nightly and I don't see it fixed yet(tried Bitwarden and LastPass).
(In reply to Coverpaint from comment #72)
> (In reply to Narcis Beleuzu [:NarcisB] from comment #71)
> > https://hg.mozilla.org/mozilla-central/rev/54679984f078
> 
> I tested the latest nightly and I don't see it fixed yet(tried Bitwarden and
> LastPass).

Upon updating today, I can say that it's fixed! Great work everybody.
Yes, it really works in 60.0a1!

Thanks to all the developers!
Comment on attachment 8951099 [details]
Bug 1324255 make webextension panels focused when opened,

(re-new the previous r+, the patch has been actually already landed)
Attachment #8951099 - Flags: review?(lgreco) → review+
Works for me too, thanks!

I still find that I have to hit TAB to actually see the cursor anywhere in the browser action popup's form.  When I do, it ends up in the field where I want it, but until I hit TAB the cursor is not present, regardless of what jquery .focus()ing I do (in particular, .focus()ing the form input in question from a setTimeout, which also has the autofocus attribute).

I'm not entirely sure if that's by design or not?
Please provide a resolution for the question in https://bugzilla.mozilla.org/show_bug.cgi?id=1324255#c76 before I can close this bug.
Flags: needinfo?(mixedpuppy)
(In reply to jjl from comment #76)

> I still find that I have to hit TAB to actually see the cursor anywhere in
> the browser action popup's form.  When I do, it ends up in the field where I
> want it, but until I hit TAB the cursor is not present, regardless of what
> jquery .focus()ing I do (in particular, .focus()ing the form input in
> question from a setTimeout, which also has the autofocus attribute).

If you use autofocus on an input element does that work?  Does the document have focus when you try to use jquery.focus?  If not, try waiting on a focus event.

https://developer.mozilla.org/en-US/docs/Web/API/Document/hasFocus
Flags: needinfo?(mixedpuppy)
Flags: needinfo?(jjl)
(In reply to jjl from comment #76)
> Works for me too, thanks!
> 
> I still find that I have to hit TAB to actually see the cursor anywhere in
> the browser action popup's form.  When I do, it ends up in the field where I
> want it, but until I hit TAB the cursor is not present, regardless of what
> jquery .focus()ing I do (in particular, .focus()ing the form input in
> question from a setTimeout, which also has the autofocus attribute).
> 
> I'm not entirely sure if that's by design or not?

I use this code and no tab is needed for me to select my input field with FF60.  Doesn't work without a setTimeout.
  
window.onload = function() {
    setTimeout(() => {
        document.getElementById("search").focus();
    }, 150);
};
With no response on the ni? and other reports that it works, this should be considered resolved.
Flags: needinfo?(jjl)
Reproduced issue on Firefox 60.0a1 (20180207220120) on Windows 10 64Bit.
Retested and verified in Firefox 61.0a1 (20180326100107) on Windows 10 64Bit, Mac OS 10.13.2.
Status: RESOLVED → VERIFIED
(In reply to Shane Caraveo (:mixedpuppy) from comment #79)
> (In reply to jjl from comment #76)
> 
> > I still find that I have to hit TAB to actually see the cursor anywhere in
> > the browser action popup's form.  When I do, it ends up in the field where I
> > want it, but until I hit TAB the cursor is not present, regardless of what
> > jquery .focus()ing I do (in particular, .focus()ing the form input in
> > question from a setTimeout, which also has the autofocus attribute).
> 
> If you use autofocus on an input element does that work?  Does the document
> have focus when you try to use jquery.focus?  If not, try waiting on a focus
> event.
> 
> https://developer.mozilla.org/en-US/docs/Web/API/Document/hasFocus

:mixedpuppy Sorry for long delay responding, I can open a new bug if that's appropriate?

Answers to your questions:

1. Yes I'm using autofocus on an input element, so no that doesn't "work" == that input element doesn't get automatically focused when the popup appears.  By "focus" here I'm talking from user/UI perspective: The field isn't highlighted and typing doesn't cause input to appear there.  If I hit TAB, I do get focus.

2. Yes, window.document.hasFocus() reports that the document has focus, both before and after my jquery.focus call

For what it's worth, the setTimeout is triggered via a couple of ajax response handlers and a chrome.runtime.getBackgroundPage callback.  The first ajax request that ends up calling that is triggered when the webextension popup shows.

Is that a bug?  If so I can try to reduce it to a minimal extension and put that somewhere (where is a good place? not sure I can upload a webextension zip to bugzilla...).
@jjl I think something is wrong with your extension.
My extension (Art Password Generator on AMO) is getting the focus without any JS hacks.
Yes indeed it was :Revertron

To inspire any stuck searchers landing here: Having just looked again at my webextension with fresh eyes I see that:

1. I had selectize (selectize.github.io) applied to my input element, which is the reason it was not focused (oops, sorry)

2. A plain old input element with autofocus is focused without the need for any setTimeout

3. For what it's worth, this allowed me to make it work with selectize (from a setTimeout): https://stackoverflow.com/questions/27566314/how-can-i-focus-on-a-selectize-select-box

Thanks again for the fix!
The setTimeout workaround only works on mac version of firefox. The only way I know that lets it auto focus on an input element is by
> setting extensions.webextensions.remote to false in about:config 
mentioned earlier (apparently this causes another bug?).
I hope there is a way other than changing something in about:config on users' end.
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.