Closed Bug 1400409 Opened 7 years ago Closed 7 years ago

When Firefox is opened and about:home is opened with its search bar disabled, the address bar is not focused.

Categories

(Firefox :: New Tab Page, defect)

57 Branch
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 57
Tracking Status
firefox57 --- fixed
firefox69 --- verified
firefox70 --- verified
firefox71 --- verified

People

(Reporter: u583215, Assigned: Mardak)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20170915100121 Steps to reproduce: Disable the search bar in about:newtab using the gear icon. Relaunch Firefox with the homepage set to about:newtab (the default). Actual results: The address bar was not focused. Expected results: The address bar should have been focused. This occurs when a subsequent new tab is opened.
Component: Untriaged → New Tab Page
Summary: When Firefox is opened and about:newtab is opened with its search bar disabled, the address bar is not focused. → When Firefox is opened and about:home (about:newtab) is opened with its search bar disabled, the address bar is not focused.
The default homepage is still about:home, but about:home has been changed to be identical to about:newtab without copying this behavior from about:newtab.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Could probably be smarter when the search box is disabled. Bug 1400585 is also wanting to not even move to the location bar in the first place.
Status: RESOLVED → REOPENED
Component: New Tab Page → Activity Streams: Newtab
Depends on: 1400585
Ever confirmed: true
Resolution: DUPLICATE → ---
Summary: When Firefox is opened and about:home (about:newtab) is opened with its search bar disabled, the address bar is not focused. → When Firefox is opened and about:home is opened with its search bar disabled, the address bar is not focused.
Assignee: nobody → edilee
Blocks: 1401418
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 57
Flags: qe-verify+
QA Contact: iulia.cristescu
When the search bar is disabled, the address bar is still not focused in about:home (even if the home page is set to its default value or if it is set to about:newtab). In fact, the behavior in 57.0b6 build1 (20171005195903) is the same like the one in 57.0a1 (2017-09-15) build. Investigated this on Windows 10 x64, Ubuntu 16.04 x64 and Mac OS X 10.11.6. Is this intended or not?
Flags: needinfo?(edilee)
The fix here got replaced by bug 1399454 after a decision change in https://bugzilla.mozilla.org/show_bug.cgi?id=1395961#c18 Although with that bug fixed, the address bar should be getting focused then when about:home is the start page.
Flags: needinfo?(edilee)
(In reply to Ed Lee :Mardak from comment #6) > Although with that bug fixed, the address bar should be getting focused then > when about:home is the start page. This (the address bar is getting focused on about:home, having the search bar disabled) happens only when opening the browser and have set it to open with the home page (and this can be set either on about:newtab, or about:newtab). When accessing the home button, this doesn't happen anymore. Does this mean that 57 build is still affected?
Flags: needinfo?(edilee)
Bug 1404674 made it so that the focus moves to the page when using the "home" button. It matches the pre-57 behavior although I'm not entirely sure what it should be for 57… I suppose one argument is that if the user clicked home instead of clicking the address bar, the focus should be in the page? That same bug was filed because someone had a custom home page, which doesn't necessarily have a focusable search box, so I think that behavior is okay for about:home.
Flags: needinfo?(edilee)
See Also: → 1404674
(In reply to Ed Lee :Mardak from comment #8) > Bug 1404674 made it so that the focus moves to the page when using the > "home" button. It matches the pre-57 behavior although I'm not entirely sure > what it should be for 57… I suppose one argument is that if the user clicked > home instead of clicking the address bar, the focus should be in the page? > That same bug was filed because someone had a custom home page, which > doesn't necessarily have a focusable search box, so I think that behavior is > okay for about:home. Based on all these details, I suppose that the verification process will be finished when the expected behavior will be assessed for 57.
We tested DevEdition 59.0b1-build9 (20180113035635) and we ran into one related potential issue: when using the Home button (and the home page is the default one), neither the in_page search bar or the location bar are focused. A different behavior is triggered when AS is disabled (browser.newtabpage.activity-stream.enabled set on false): the focus is set on the search bar. And this seems to be the expected outcome, as the new tab case triggers the location bar focus (with and without AS). What is your opinion regarding these?
Flags: needinfo?(edilee)
The behavior changed for 59 with bug 1417943 by making the in page search box no longer automatically getting focus when the page is focused. Clicking the home button does move focus to the page, and pressing space scrolls the page like any other page that doesn't focus an input box. I suppose a separate bug could be filed to have the address bar focused when clicking on the home button and the home page is the default home page… although the user could have just clicked on the address bar in the first place?
Flags: needinfo?(edilee)
See Also: → 1417943
Component: Activity Streams: Newtab → New Tab Page

According to this bug's comment history, then it appears that the latest main Firefox versions no longer reproduce the original issue.

My steps to test are:

  1. Open the browser with a new profile.
  2. Set the Homepage as "about:newtab".
  3. Close and reopen.
  4. Notice which section/input box is focused.

Broken: The address bar is not focused.
Correct: The address bar is focused.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.