From https://www.reddit.com/r/firefox/comments/h77vhw/does_anyone_know_how_to_make_firefox_focus_on_the/fukh5ji/

Steps to reproduce:

1. Disable "Show search suggestions in address bar results" in about:preferences
2. Type into NTP search bar

What happens:

Search is handed off to address bar, suggestions don't appear.

Expected result:

The search is not handed off because the user expects to continue to receive search suggestions when searching from the search bar in NTP, but does not expect it in the address bar.

The handoff works correctly in that it does not show suggestions after handoff, but this represents a UX regression for those who expect to see search suggestions in NTP.

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit auto_nag documentation.

Hi Asif,

Do you have browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar set to false in about:config?

I'm not able to replicate your issue, let me know if i'm missing any step. I deactivated the setting above, and also disabled "Show search suggestions in address bar results" in about:preferences, but still not able to reproduce.

I'm using windows 10 pro, firefox nightly 79.0a1 (2020-06-29) (64-bit).

Best,
Clara

Clara,

browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar is set to true for me, and I suspect that is due to the fact that I am running a Nightly version.

The regression here is that there was no preference to disable autocomplete in the NTP, and handoff to the addressbar breaks user expectations here.

Let me know if that makes sense.

I think it is reasonable that with the hand-off to the address bar, the new tab page bar is treated the same as the address bar. The slight difference here is the @<engine> change that happens when going through the hand-off, and that's generating suggestions. Maybe that needs thinking about from UX, but maybe that's expected.

There's still a separate search bar, so the preference still makes some sense - though I think I've heard comments about UX wanting to change that section.

Moving across to address bar, as that's where this is most likely to need work.

This is up to UX/product, but as I understand it, the point of all our work in search/urlbar is to drive users to the urlbar for searches. That's why hand-off is there, that's why we show suggestions in the urlbar, that's why the search bar is not enabled in new profiles. It would be counterproductive to that effort to continue to support the search field in the new tab page as a first-class access point. We could have an exception for people who've disabled suggestions, but I doubt there's an argument there that's good enough to make it worth maintaining the new-tab search field.

But hand-off is still Nightly only (I think), and as I say it's up to UX/product.

As an alternative, it's much easier to imagine showing suggestions in the urlbar for one time only after hand-off.

With the update-2 redesign this is fixed because search mode always provides search suggestions. Though, if we fix bug 1616700, this is valid again.

And this is valid again because hand-off now doesn't enter Search Mode (differently from CTRL+K). Product so far isn't worried about this. I guess we'll check numbers and users feedback. One side we'd like the hand-off experience to be as straight-foward as possible, and we've seen users confused by the Search Mode chiclet. We also want to provide more value in the default urlbar mode. The other side this was some sort of onboarding to Search Mode. This can probably stay a low priority unless we hear real world issues.

Discussed this with mconnor, he suggested we pick same solution as bug 1713827.

I struggled with this issue on upgrading to version 89. Setting browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false resolved my issue but I only learned of this setting by filing a bug report. I suspect other users are struggling with this as well.

The notion that it's okay to redirect users that use the web search box on the new tab page to the URL/address bar so that all of my search capabilities can be muddled together in one awesome input box is seriously flawed. If I wanted to search from the address bar, I would have clicked in there. Combining search and URL history is a terrible idea IMO. We have all this real estate on the computer screen yet I have to do all my work from one place?

(In reply to Drew Willcoxon :adw from comment #5)

This is up to UX/product, but as I understand it, the point of all our work in search/urlbar is to drive users to the urlbar for searches. That's why hand-off is there, that's why we show suggestions in the urlbar, that's why the search bar is not enabled in new profiles. It would be counterproductive to that effort to continue to support the search field in the new tab page as a first-class access point. We could have an exception for people who've disabled suggestions, but I doubt there's an argument there that's good enough to make it worth maintaining the new-tab search field.

But hand-off is still Nightly only (I think), and as I say it's up to UX/product.

As an alternative, it's much easier to imagine showing suggestions in the urlbar for one time only after hand-off.

Hi Drew,
Commenting on an old post here, but I want to say driving users to the urlbar for searches is a bad idea for people with vision problems. I can't easily see what I'm typing in the urlbar, and I don't want bigger text there either (takes up space n my small screen), so I hope you'll leave the preference browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar available, at least.
Regards, Bob H

Hi Bob, we're not planning on keeping that preference around for long. Can you say more about your use case? IIRC the text size of the search field in the new-tab/home page wasn't much different from the text size in the urlbar; did you increase the zoom in the page? If so, I would think that it would also take up space on your screen, so can you say more about why you wouldn't want to do that for the urlbar?

Fixed in bug 1713827.