Open Bug 1645293 Opened 1 year ago Updated 12 hours ago

Searching from newtab activity stream with handoff to awesomebar does not allow user to receive search suggestions if search suggestions are disabled in preferences


(Firefox :: Address Bar, defect, P3)

67 Branch




(Reporter: yoasif, Unassigned)


(Depends on 1 open bug, Blocks 2 open bugs, Regression)


(Keywords: blocked-ux, regression)


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.

Blocks: 1344931, 1501747
Regressed by: 1508388
See Also: → 1552463

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(sdowne)

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).


Flags: needinfo?(yoasif)


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.

Flags: needinfo?(yoasif)
Component: New Tab Page → Search
Flags: needinfo?(sdowne)

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.

Component: Search → Address Bar

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.

Severity: -- → S4
Keywords: blocked-ux
Priority: -- → P5

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.

Depends on: 1616700

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.

Depends on: 1713827
Severity: S4 → S3
Priority: P5 → P3
Duplicate of this bug: 1716237
You need to log in before you can comment on or make changes to this bug.