Closed Bug 1645293 Opened 4 years ago Closed 3 years 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

Categories

(Firefox :: Address Bar, defect, P3)

67 Branch
defect
Points:
2

Tracking

()

RESOLVED FIXED
Iteration:
91.2 - Jun 14 - Jun 27

People

(Reporter: yoasif, Assigned: bugzilla, NeedInfo)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: blocked-ux, regression)

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.

Blocks: 1344931, 1501747
Regressed by: 1508388
See Also: → 1552463
Has Regression Range: --- → yes

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

Best,
Clara

Flags: needinfo?(yoasif)

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.

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

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?

Flags: needinfo?(bobh)
Assignee: nobody → htwyford
Status: NEW → ASSIGNED
Iteration: --- → 91.2 - Jun 14 - Jun 27
Points: --- → 2

Fixed in bug 1713827.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.