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)
WebExtensions
Frontend
Tracking
(firefox58 wontfix, firefox59 wontfix, firefox60 verified, firefox61 verified)
VERIFIED
FIXED
mozilla60
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.
Reporter | ||
Comment 1•7 years ago
|
||
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•7 years ago
|
Priority: -- → P3
Whiteboard: triaged
Reporter | ||
Comment 2•7 years ago
|
||
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?
Reporter | ||
Comment 3•7 years ago
|
||
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);
Reporter | ||
Comment 4•7 years ago
|
||
Also, the regression I mentioned in comment 2 is also present in FDE 52.0a2 (2016-12-19)
Assignee | ||
Updated•7 years ago
|
Summary: Opening a browser action popup does not focus it → Opening a popup does not focus the browser frame
Comment 10•7 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...
Reporter | ||
Comment 11•7 years ago
|
||
The delay workaround seems to be working for me in 57.0a1 (2017-08-15)
Comment 12•7 years ago
|
||
I'm sorry, I really does work :) Thank you! I must have done something wrong with my initial attempts...
Comment 13•7 years ago
|
||
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•7 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•7 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•7 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•7 years ago
|
||
Yes I can confirm both Beta (56.0b8) and Nightly channels are now affected with this bug.
Comment 21•7 years ago
|
||
This is up to 6 dupes. We should probably prioritize it higher.
Priority: P3 → P1
Comment 22•7 years ago
|
||
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•7 years ago
|
Assignee: nobody → mixedpuppy
Assignee | ||
Comment 23•7 years 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•7 years 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•7 years 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.
Updated•7 years ago
|
Attachment #8919493 -
Flags: feedback?(kmaglione+bmo) → feedback+
Comment hidden (mozreview-request) |
Assignee | ||
Updated•6 years ago
|
Flags: needinfo?(gijskruitbosch+bugs)
Comment 28•6 years 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•6 years 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•6 years ago
|
||
Is there a way to avoid this problem in Firefox 57? It is very troubling when creating WebExntensions version.
Assignee | ||
Comment 31•6 years 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•6 years 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•6 years ago
|
||
Err, without the useless lazy import: https://pastebin.mozilla.org/9072864
Comment 34•6 years 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•6 years 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•6 years ago
|
||
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•6 years ago
|
Flags: needinfo?(gijskruitbosch+bugs)
Comment 37•6 years 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)
Comment 38•6 years ago
|
||
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•6 years ago
|
||
Gijs, the pastebins expired, do you have that patch?
Flags: needinfo?(mixedpuppy) → needinfo?(gijskruitbosch+bugs)
Comment 40•6 years 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•6 years 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.
Comment 43•6 years 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•6 years 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•6 years 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•6 years 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•6 years ago
|
Comment 48•6 years 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) |
Assignee | ||
Comment 50•6 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=eefe98e8e93b9f0cac22883a762e43f66f19b3d9
Comment hidden (mozreview-request) |
Assignee | ||
Comment 52•6 years 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.
Assignee | ||
Comment 53•6 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a9d1b0df60018128e3a9d094133153acc3bf28d9
Comment hidden (mozreview-request) |
Assignee | ||
Comment 55•6 years 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•6 years 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•6 years 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•6 years ago
|
Flags: needinfo?(lgreco)
Assignee | ||
Comment 58•6 years 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•6 years ago
|
Attachment #8919493 -
Attachment is obsolete: true
Comment hidden (mozreview-request) |
Assignee | ||
Updated•6 years ago
|
Attachment #8950770 -
Attachment is obsolete: true
Attachment #8950770 -
Flags: review?(lgreco)
Attachment #8950770 -
Flags: review?(gijskruitbosch+bugs)
Comment 61•6 years 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•6 years 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•6 years ago
|
Attachment #8950794 -
Attachment is obsolete: true
Attachment #8950794 -
Flags: review?(lgreco)
Attachment #8950794 -
Flags: review?(gijskruitbosch+bugs)
Assignee | ||
Comment 64•6 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba5b9774ad9fe708789f2f0497164de3f88265fd
Comment 65•6 years 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•6 years 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•6 years ago
|
Attachment #8951035 -
Attachment is obsolete: true
Attachment #8951035 -
Flags: review?(lgreco)
Assignee | ||
Comment 68•6 years 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•6 years 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+
Assignee | ||
Comment 70•6 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/54679984f078c4158d357c2968e464bb8c01f98b Bug 1324255 make webextension panels focused when opened, r=Gijs,rpl
Comment 71•6 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/54679984f078
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
Updated•6 years ago
|
Comment 72•6 years 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•6 years 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•6 years ago
|
||
Yes, it really works in 60.0a1! Thanks to all the developers!
Comment 75•6 years ago
|
||
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•6 years 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?
Comment 78•6 years 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•6 years 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•6 years ago
|
Flags: needinfo?(jjl)
Comment 80•6 years 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•6 years ago
|
||
With no response on the ni? and other reports that it works, this should be considered resolved.
Flags: needinfo?(jjl)
Comment 82•6 years 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•6 years ago
|
Comment 83•6 years 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•6 years 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•6 years 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•6 years 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•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•