When you open a new window, the focus is on the location bar first and then, after a bit, on the search field in the content page. This is a problem because of two reasons: 1) the focus change is noticeable, even on my fast machine; 2) if the machine is slow or busy on something else and you start typing as soon as a new window is opened, you will end up with half your sentence in the location bar and half in the search field.

Some initial exploration shows that the earliest Activity Stream can focus the browser is still too late as location bar has already grabbed focus, so there will need to be some change outside of the extension to prevent it from focusing the location bar. Not sure if the behavior should be checking `browser.newtabpage.activity-stream.aboutHome.autoFocus` but the default for that only exists once the add-on is initialized. Although if the user has set a value, the pref would then be available.

Can we keep the focus on the location bar instead? It is far more powerful than the search field, since the awesome bar also has suggestions from history.

That's a decision that needs to be made in and your reasoning is similar to bug 1395961 comment 12 from madhava.

Hi y'all, NChapman, Maria, and I are talking about this one. We've been slammed and while I didn't comment in the other bug 1395961. The URLbar is the future, as Madhava said. We don't have time to do a Shield test before 57, and that's why we stayed status quo in that bug. However, I immediately noticed this effect on Nightly today, and Maria pointed me to this bug. I'm concerned about this being interpreted as a perceived performance problem by our users, if the cursor leaps from URlbar down to the in-content page. I'm asking UR/UX for their opinion here. I'd like to hear what they have to say but I'm in favor of going to URLbar if folks agree that's the best course to minimizing user disruption.

There's an agreement from AS UX (Bryan Bell and Aaron Benson) that 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.

That works for me Maria, thank you for sorting that out! And again my apologies. We're also slammed on 57 stuff. We couldn't A/B test this prior, so we punted on a decision in case this impacted the UX. But as we see when rolling back to prior state (in-content bar focus), the inability of Firefox to allow the in-content bar to be equal to the URLbar creates an unintended side effect.

The fix for this is probably just doing the opposite of bug 1399454 with a bunch of pref checks. Although given the decision to keep the focus in the location bar and only running into this bug when the user or shield study changes `browser.newtabpage.activity-stream.aboutHome.autoFocus` the priority of this bug is much lower if not wontfix until the default behavior changes.

(In reply to Ed Lee :Mardak from comment #7) > The fix for this is probably just doing the opposite of bug 1399454 with a > bunch of pref checks. Although given the decision to keep the focus in the > location bar and only running into this bug when the user or shield study > changes `browser.newtabpage.activity-stream.aboutHome.autoFocus` the > priority of this bug is much lower if not wontfix until the default behavior > changes. Note the study results could be affected by the bug, so maybe this should be a blocker for the study.

(In reply to Marco Castelluccio [:marco] from comment #8) > (In reply to Ed Lee :Mardak from comment #7) > > The fix for this is probably just doing the opposite of bug 1399454 with a > > bunch of pref checks. Although given the decision to keep the focus in the > > location bar and only running into this bug when the user or shield study > > changes `browser.newtabpage.activity-stream.aboutHome.autoFocus` the > > priority of this bug is much lower if not wontfix until the default behavior > > changes. > > Note the study results could be affected by the bug This doesn't really seem plausible to me.

Here's a video of the current behavior that shield study users would see (assuming bug 1399454 is uplifted). On my fast machine, it takes 100ms for the window to be fully sized, then 133ms for Activity Stream to grab focus from location bar, then 366ms for the search box to render. So for users on much slower machines, there is the possibility of early keystrokes not ending up in the search box. Although also unclear how many users open a new window and start typing immediately. marco, Activity Stream did make changes to grab focus earlier since you first filed this bug.

Commit pushed to master at https://github.com/mozilla/activity-stream https://github.com/mozilla/activity-stream/commit/bb4726eb42778e9bdc060ba0fce0b3cd6d370d25 fix(search): Close Bug 1417943 - in-page search box gets focus after entering input in location bar (only on initial tab at browser startup) (#3881) Also fix Bug 1400585 - With activity-stream.aboutHome.autoFocus set, initil focus is in the address bar then moves to content search Also fix Bug 1421417 - Focus moves to about:home search box when turning on the search preference