[Tracking Requested - why for this release]: This is a recent regression from bug 1393802. It's caused by this line: https://hg.mozilla.org/integration/autoland/rev/434a7900c855#l4.14 Before this, the big search field in the middle of about:home was getting focused at startup.
I believe the plan is to switch about:home to activity stream. Bug 1392324 added a pref for this.
(In reply to Dão Gottwald [::dao] from comment #1) > I believe the plan is to switch about:home to activity stream. Bug 1392324 > added a pref for this. Changing the element focused by default on startup & new window should be a UX decision, not something happening by accident. The new behavior causes at least 2 issues: - the awesomebar tour starts at startup, and is partly above the tour thing in the top left corner of about:home/about:newtab - the focus change on the awesomebar during startup visibly flickers (we would need to focus it before first paint if we do want the location bar focused by default).
(In reply to Florian Quèze [:florian] [:flo] from comment #2) > The new behavior causes at least 2 issues: > - the awesomebar tour starts at startup, and is partly above the tour thing > in the top left corner of about:home/about:newtab I'm fixing that in bug 1384050
(In reply to Florian Quèze [:florian] [:flo] from comment #2) > (In reply to Dão Gottwald [::dao] from comment #1) > > I believe the plan is to switch about:home to activity stream. Bug 1392324 > > added a pref for this. > > Changing the element focused by default on startup & new window should be a > UX decision, not something happening by accident. Well, I was anticipating that we're going to make about:home even more consistent with about:newtab -- I think that's what motivated bug 1393802 in the first place -- so it wasn't an accident on my part. There are other ways to implement bug 1393802, but making isBlankPageURL("about:home") == true gets us the most consistency overall.
Summary: The location bar gets focus at startup and on new windows → The location bar gets focus at startup and on new windows (instead of search field of about:home)
And this is a inconsistent behavior because about:home search field gets focus when I open about:home again. And This problem is only on Nightly57.0a1 with e10s.
Does this bug still have something actionable in it?
(In reply to Jim Mathies [:jimm] from comment #7) > Does this bug still have something actionable in it? Err, did you mean to comment on a different bug? This bug is 5 days old and a regression in 57. Definitely actionable.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(jmathies)
Commenters were listing related bugs that have been marked fixed, so I was just checking to see if there was still work to do here. Sounds like there is.
It sounds like it's quite possible that the desired focus behavior is to keep focus in the location bar on launching Firefox, new windows, etc. Who needs to decide? Adding various people. mconnor, we had chatted about Activity Stream's autofocusing in-page or not, and it looks like Nightly currently treats about:home auto-focus behavior the same as about:newtab, i.e., focus stays in the location bar on new window and new tab. Notes from mconnor back on August 31st: > from a user task flow perspective, I think it’s weird to assume that opening the browser and opening a new tab are different enough as to require different defaults > big picture, someone who’s going to search is going to search, regardless of focus > but I’m not sure why we would have divergent defaults between about:home and about:newtab for any reason other than historical (location bar default on new tab was established because new tab was blank). One benefit of having focus in the location bar is that potentially, the hero element timing moves from "in-content search rendered" to "location bar rendered" which will be sooner than about:home.
From an armchair UX position, I think the quote above is correct. If we are unifying new tab and home page into one experience, it should be consistent in experience, including keyboard focus. New window vs. new tab should get the same interaction model. I think the inconsistency we have today has legit historical reasons, but we should take the opportunity of fixing it now that we've unified the experience. * Location bar lets you search or navigate, so there's a greater range of possibility there. It's also consistent with Chrome (same behaviour for new window or new tab). * Search box lets you search or quickly tab to Top Sites, so there's an interesting angle on different functionality for keyboard users. (Chrome actually moves focus to the location bar if you type into the content search field, so they make it a little bit moot.) At this point, I'd argue that we should default to focusing the location bar in all cases. * New tab is a much more common interaction than new window for most users, so we'll have the smallest amount of disruption. * The location bar allows both navigation and search, so the user never needs to switch focus. * Consistency with Chrome/Safari, not sure about IE/Edge (don't have a Windows PC handy to check)
The location bar is, now, and is going to be even more so over time the tool with the most functionality -- and the thing that we're going to be working to improve. That's where we should be guiding people. I'm going to additionally NI Javaun here, on the basis that this should be on the radar of people paying to attention to how people search.
Flags: needinfo?(madhava) → needinfo?(jmoradi)
Activity Stream just met to reprioritize autofocusing the content search box for now to be conservative in changing behavior right now. We will implement it with a pref so that it can be turned on/off during Beta 57 with a shield study to study its effect on total search volume. https://github.com/mozilla/activity-stream/issues/2007 Although, if there is a higher level Firefox decision to keep focus in the location bar independent of a study outcome, then we could WONTFIX this… (and save on some engineering… ;))
Why *is* there a search field in the New Tab / Home page? (It seems redundant with the location bar.)
(In reply to Madhava Enros [:madhava] from comment #12) > The location bar is, now, and is going to be even more so over time the tool > with the most functionality -- and the thing that we're going to be working > to improve. That's where we should be guiding people. javaun, osunick: What's needed to decide where the focus should be going forwards from 57? As madhava pointed out in comment 12, it sounds like the location bar is where focus should be in the future, so should it be focused now? There are at least 2 competing bugs that are opposites depending on the decision in this bug. Bug 1399454 wants focus in the location bar sooner while bug 1400585 doesn't want focus in the location bar at all. One needs to be WONTFIXed.
Hi folks, There have been many conversations had outside of this bug so here's the summary of those: 1. We all agree that moving focus to the address bar seems to make the most sense, and we'd like to do that. 2. That being said, we don't want to negatively impact the search experience for our users, and we have a lot of evidence that our users are split on using the address bar and the in-content search boxes. 3. We are currently running tests around unifying the address bar and search box in the toolbar. We want to run a similar test on the focus of this search box as well, but it must wait until we've finished those tests. 4. Javaun will put this test into their queue, and we'll make a decision as soon as the data is available. That means that the decision at this time is to maintain the current behavior in Firefox until we have proper data to make a decision to change it. This behavior is now behind a pref (browser.newtabpage.activity-stream.aboutHome.autoFocus) so it'll be easy to change when we're ready. Thanks so much, Nick Chapman
With that decision from comment 16, sounds like this bug is working as intended. But the other bug 1400585 and bug 1399454 both actually need to get fixed because the user / a shield study can change the behavior to focus about:home or location bar. dao, any suggestions on how to focus location bar earlier as well as keeping focus in the selected browser/content depending on whether Activity Stream is enabled on about:home (browser.newtabpage.activity-stream.aboutHome.enabled) AND whether it's autofocusing (browser.newtabpage.activity-stream.aboutHome.autoFocus)? (The latter pref only gets a default set when activity stream is initialized, but it could have been toggled to `false` by the user or shield study.) (Or if you want to follow up in the other bugs individually.)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
Bug bug 1400585 updated with following comment: The location bar is the future and I'm in support of it. There's no need to short focus from location to search on about:home.
(In reply to Ed Lee :Mardak from comment #17) > With that decision from comment 16, sounds like this bug is working as > intended. But the other bug 1400585 and bug 1399454 both actually need to > get fixed because the user / a shield study can change the behavior to focus > about:home or location bar. > > dao, any suggestions on how to focus location bar earlier as well as keeping > focus in the selected browser/content depending on whether Activity Stream > is enabled on about:home > (browser.newtabpage.activity-stream.aboutHome.enabled) AND whether it's > autofocusing (browser.newtabpage.activity-stream.aboutHome.autoFocus)? (The > latter pref only gets a default set when activity stream is initialized, but > it could have been toggled to `false` by the user or shield study.) > > (Or if you want to follow up in the other bugs individually.) I discussed this with Andreio. Fixing this properly might be tricky, but if it's just for the study, we can add hacks that just check these prefs. Then again, if it's just for the study, I wouldn't worry about these bugs in the first place.
Nod. Seems like things have changed in the last day. With comment 18, the default will be focus in the location bar, so bug 1399454 should have a higher priority than bug 1400585, which would only happen if the user changes an about:config pref or via shield study.
Sounds like this is now wontfix for 57.
You need to log in before you can comment on or make changes to this bug.