1519713 - search handoff is suboptimal when a user has previous disabled search suggestions in the address bar

Status: RESOLVED WORKSFORME

(Firefox :: New Tab Page, defect, P1)

Description

[Asa Dotzler [:asa]]

Search handoff, as implemented in bug 1508388, is inappropriate for users who have disabled search in the addressbar (something supported by prefs UI). These users who want to search the web are completely broken by search handoff.

Steps to reproduce:

1. disable search in the awesomebar in about:preferences#search by unchecking "Show search suggestions in addressbar results"
2. open a new tab page, select the in-content search box, and start typing your web search term(s)

Results: typing is transferred to the addressbar which does not offer search results.

Expected results: web search is available and completed from in-content search box.

Comment 1

[Chris Peterson [:cpeterson]]

Also, if the user has the Search bar in their toolbar (by selecting "Add search bar to toolbar" in about:preferences#search), then selecting the new tab's in-content search box will focus the address bar even though the user has configured their Firefox to use the separate Search bar.

Comment 2

[Mike Connor [:mconnor]]

To clarify a bit of comment 0, disabling suggestions doesn't actually disable search, just whether we show suggestions. I don't think the "expected results" is right, but I agree this isn't optimal within current constraints. We can be more nuanced here.

On comment 1, the search bar being enabled is either grandfathered (profile predates 57) or the user re-enabled it. Not sure if we can reliably detect the difference at runtime.

cc-ing relevant UX folks.

Simple proposal for reducing friction for this transition:

• If urlbar suggestions are enabled, maintain current behaviour.
• If suggestions are disabled for all search (including in private browsing contexts), maintain current behaviour
• If suggestions are enabled AND urlbar suggestions are disabled AND the search bar is visible, focus the search bar instead of the address bar. (assumption: user is bifurcating search and navigation between access points)
• The last possibility (urlbar suggestions disabled, suggestions enabled, no searchbar) seems like a corner case, but if we can't agree on the optional bits quickly, we can not hand off for now.

Optional concepts to discuss:

• auto-add the the ? modified to the handoff to limit the action to search
• If addressbar suggestions are disabled, but suggestions are enabled, we should show suggestions when the ? prefix is used.
  • We'd have to clarify the behaviour in the prefpane (show search suggestions: Never/When I'm searching/always)
  • this allows combined bar users to have the same bifurcation of functionality as they do with two bars, driven by keyboard shortcuts, and possibly clicks on a magnifying glass icon

If we can combine the optional concepts, we get the same interaction flow as today (suggestions when clicking in-content, no suggestions when clicking urlbar), even though the bar is the same.

Comment 3

[Mark Banner (:standard8)]

Moving across to activity stream, since that's where this was implemented and is likely to be the place for any changes.

Comment 4

[Mike Connor [:mconnor]]

From followup discussion investigation, there's another case to consider: keyword.enabled (which is a legacy pref that actually
disables search). That’s a Netscape-era pref that’s survived down the years, and used to be paired with ‘keyword.url’ The ‘keyword’ behaviour is a fallback for when a user didn’t type a recognized URL. This was more like AOL keywords than search, at least in the beginning.

In Firefox we originally used Google’s I’m Feeling Lucky to convert non-URLs to navigable , then we moved to “Browse by Name” which is basically IFL for super obvious matches, but otherwise show search results. At some point we went to straight search, and started using the current default engine instead of a separate, non-configurable

That said, the intent of that pref was always “never fall back to keyword lookup/search”. I think it’s viable/acceptable to perform a search IFF the user is explicitly searching (i.e. using the ? prefix).

In general, I'm leaning toward using the ? prefix for the handoff. The user intent is explicitly to search, so we lose nothing by limiting to search.

Comment 5

[Ricky Rosario [:rrosario, :r1cky]]

In the "Search + Activity Stream" meeting, we decided that we will prepend '@google ' (or @keyword for the user's default engine) to whatever the user types when handing off. This limits the awesomebar to just do a search just like prepending '? ' but it should look less like a bug to the user.

Comment 7

[Tim Spurway [:tspurway]]

:mconnor do you think this bug blocks PBM and the AS experiment in 66 release? I am trying to figure out if we need to uplift a fix here

Comment 8

[Ricky Rosario [:rrosario, :r1cky]]

To clarify, Comment 5 (@-shortcut prefixing) has already landed and is in Beta 66.

Handing off to the searchbar, if available, when urlbar suggestions are disabled is not implemented. If this is an issue, we can run the experiment in Release 66 with only users that have urlbar suggestions enabled. And if that's cool, we don't need this for 66.

Then the question is, do we need this for 67? I personally find the hand-off from in-content search to the small searchbar up on the top right to be a very awkward user experience.

Comment 9

[Mike Connor [:mconnor]]

Ack, missed this. This is not a blocker, and I agree we shouldn't do it. We're looking to consolidate usage to best leverage the QuantumBar. I think this is WORKSFORME at this point due to other bugs? Asa, ping me if you disagree.