This is the original bug report for Bug 1634272, on that bug I fixed a different problem, so I'm filing a new bug to track the original problem:

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

install Group Speed Dial extension:
https://addons.mozilla.org/sk/firefox/addon/groupspeeddial/
click its toolbar icon / Options
in the Options page, click the "Copy homepage link" button (first line)
open "about:preferences#home" page and change the "Homepage and new windows" to "Custom URLs" and paste there the link
open New tab
type to addressbar "github.com" and press enter
press "Alt + Home" short-key

Actual results:

Addressbar is NOT focused

Expected results:

Addressbar should be focused.
This works in release 75 and ESR 68.
I can reproduce it in Beta 76.0b8 and Nightly 77

Hi Gijs,

Your name came up when I was talking with some people about "about:home". If you're the wrong person do you know who is the right person?

I've been looking at this bug but all the code that does the focus/not-focus the URL bar decision just checks for whether the URI is one of the blank pages using isBlankPageURL:

https://searchfox.org/mozilla-central/source/browser/base/content/utilityOverlay.js#74

I don't see any special handling for extensions. But the browser used to behave this way, at least with the extension in Bug 1634272 (I'll check there next to see if it's doing something special). So my question is. What's the intended behaviour of the browser? Does this already works as intended?

Thanks.

Before someone marks this as "Working as intended" by accident, I would like to point out that this is:

1. not consistent - why should focusing addressbar behavior differ based on the URL on I use
2. not consistent - addressbar is focused when New tab is opened, when new window is opened, when "Alt + Home" is pressed second time, when "Alt + Home" is pressed and user is on any extension page (so based on protocol???)
3. not how it was working for years, so please don't make my life harder :)

It may be worth discussing whether to allow extensions overriding New tab page to control addressbar focus while their tab is focused.

(In reply to Paul Bone [:pbone] from comment #1)

So my question is. What's the intended behaviour of the browser? Does this already works as intended?

I'm pretty sure we're supposed to focus the address bar in the case described in comment #0 - the address bar is cleared (rather than showing the URL) so it's ready for typing.

I've been looking at this bug but all the code that does the focus/not-focus the URL bar decision just checks for whether the URI is one of the blank pages using isBlankPageURL:

https://searchfox.org/mozilla-central/source/browser/base/content/utilityOverlay.js#74

I don't see any special handling for extensions.

It's maybe not obvious, but the extension overrides the default new tab page, and the code at https://searchfox.org/mozilla-central/rev/f66f5a235e7d74c29b951316f73001126a056734/browser/base/content/utilityOverlay.js#33-65 means that BROWSER_NEW_TAB_URL should match. Which means that the utilityOverlay.js code you referenced, which is called (among others) from https://searchfox.org/mozilla-central/rev/f66f5a235e7d74c29b951316f73001126a056734/browser/base/content/browser.js#2857-2861 should match the URL copied in the STR.

I did a quick test and the URL the extension provides does indeed match BROWSER_NEW_TAB_URL (when overriding the new tab is permitted), so it's not clear to me off-hand why this isn't working. Have you looked for another place where focus changes, and/or used logging to verify what happens when isBlankPageURL is called?

You can actually see that the addressbar gets focused for a moment and then it looses the focus.

We should add a test to browser_navigate_home_focuses_addressbar.js for this specific case.

Depends on D83754

Hi Kashav,

Here's what I have so far. I think that the test is correct but it's not passing yet (at least in my workspace with some other changes).

You're welcome to take this if you'd like, but I'm just as happy to finish it.

Thanks Paul. I had a similar test that was also failing locally. I can try to figure out what's going wrong.

Backed out 2 changesets (bug 1643578) for Browser-chrome failures in browser_navigate_home_focuses_addressbar.js. CLOSED TREE

Log:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=310878244&repo=autoland&lineNumber=7610

Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=e87edc47ce4966ef9cf2df591dfa8a0d66f57116

Backout:
https://hg.mozilla.org/integration/autoland/rev/7590205c21846121ab0c0a7e1158ac7b555c9cba

This was the test I added. I'll take a look.

Thanks kashav.

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:kashav, could you have a look please?
For more information, please visit auto_nag documentation.

Clearing assignee because Kashav is no longer at Mozilla.