Opening a popup does not focus the browser frame

VERIFIED FIXED in Firefox 60

Status

P1
normal
VERIFIED FIXED
2 years ago
9 months ago

People

(Reporter: kumar, Assigned: mixedpuppy)

Tracking

(Depends on: 1 bug)

unspecified
mozilla60
Dependency tree / graph

Firefox Tracking Flags

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

Details

(Whiteboard: triaged)

Attachments

(6 attachments, 4 obsolete attachments)

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.

Updated

2 years ago
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)
Duplicate of this bug: 1338909
Duplicate of this bug: 1366746
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1365222
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1364390
(Assignee)

Updated

2 years ago
Summary: Opening a browser action popup does not focus it → Opening a popup does not focus the browser frame
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1381254

Comment 10

2 years ago
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)

Comment 12

2 years ago
I'm sorry, I really does work :) Thank you!
I must have done something wrong with my initial attempts...

Comment 13

2 years ago
Posted 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)

Comment 14

2 years ago
@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).

Comment 15

2 years ago
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.

Comment 16

2 years ago
I have this same problem in Nightly 57.0a1 (2017-09-02) (64-bit). The workaround doesn't seem to work

Comment 17

2 years ago
Yes I can confirm both Beta (56.0b8) and Nightly channels are now affected with this bug.
Duplicate of this bug: 1396385
Duplicate of this bug: 1402231
Duplicate of this bug: 1404411
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.

Updated

2 years ago
Assignee: nobody → mixedpuppy
(Assignee)

Comment 23

a year ago
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 hidden (mozreview-request)
(Assignee)

Comment 25

a year ago
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 26

a year ago
mozreview-review
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+
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Flags: needinfo?(gijskruitbosch+bugs)

Comment 28

a year ago
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)
(Assignee)

Comment 29

a year ago
(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)

Comment 30

a year ago
Is there a way to avoid this problem in Firefox 57?
It is very troubling when creating WebExntensions version.
(Assignee)

Comment 31

a year ago
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)

Comment 32

a year ago
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)

Comment 33

a year ago
Err, without the useless lazy import: https://pastebin.mozilla.org/9072864

Comment 34

a year ago
(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 .
(Assignee)

Comment 35

a year ago
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)
(Assignee)

Comment 36

a year ago
Posted 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.

Updated

a year ago
Flags: needinfo?(gijskruitbosch+bugs)

Comment 37

a year ago
(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
(Assignee)

Comment 39

a year ago
Gijs, the pastebins expired, do you have that patch?
Flags: needinfo?(mixedpuppy) → needinfo?(gijskruitbosch+bugs)

Comment 40

a year ago
(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)

Comment 41

a year ago
(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.
Duplicate of this bug: 1426841

Comment 43

a year ago
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)

Comment 44

a year ago
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.

Comment 45

a year ago
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 hidden (mozreview-request)

Comment 47

a year ago
mozreview-review
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+
(Assignee)

Updated

a year ago
status-firefox58: --- → wontfix
status-firefox59: --- → affected
status-firefox60: --- → affected

Comment 48

a year ago
mozreview-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+
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Comment 52

a year ago
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.
Comment hidden (mozreview-request)
(Assignee)

Comment 55

a year ago
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 56

a year ago
mozreview-review
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 57

a year ago
mozreview-review
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).

Updated

a year ago
Flags: needinfo?(lgreco)
(Assignee)

Updated

a year ago
See Also: → bug 1435687
(Assignee)

Comment 58

a year ago
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.
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Attachment #8919493 - Attachment is obsolete: true
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Attachment #8950770 - Attachment is obsolete: true
Attachment #8950770 - Flags: review?(lgreco)
Attachment #8950770 - Flags: review?(gijskruitbosch+bugs)

Comment 61

a year ago
mozreview-review
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 62

a year ago
mozreview-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)
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Attachment #8950794 - Attachment is obsolete: true
Attachment #8950794 - Flags: review?(lgreco)
Attachment #8950794 - Flags: review?(gijskruitbosch+bugs)

Comment 65

a year ago
mozreview-review
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 66

a year ago
mozreview-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+
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Attachment #8951035 - Attachment is obsolete: true
Attachment #8951035 - Flags: review?(lgreco)
(Assignee)

Comment 68

a year ago
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 69

a year ago
mozreview-review
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+

Comment 71

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/54679984f078
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox60: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
status-firefox59: affected → wontfix

Comment 72

a year ago
(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).

Comment 73

a year ago
(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.

Comment 74

a year ago
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+

Comment 76

a year ago
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?
(Assignee)

Updated

a year ago
Duplicate of this bug: 1402227

Comment 78

a year ago
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)
(Assignee)

Comment 79

a year ago
(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)
(Assignee)

Updated

a year ago
Flags: needinfo?(jjl)

Comment 80

a year ago
(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);
};
(Assignee)

Comment 81

a year ago
With no response on the ni? and other reports that it works, this should be considered resolved.
Flags: needinfo?(jjl)

Comment 82

a year ago
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.

Updated

a year ago
Status: RESOLVED → VERIFIED
status-firefox60: fixed → verified
status-firefox61: --- → verified

Comment 83

a year ago
(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...).

Comment 84

a year ago
@jjl I think something is wrong with your extension.
My extension (Art Password Generator on AMO) is getting the focus without any JS hacks.

Comment 85

a year ago
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!

Comment 86

11 months ago
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.

Updated

9 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.