Closed Bug 1678138 Opened 4 years ago Closed 3 years ago

Add a Preferences toggle for tab-to-search results

Categories

(Firefox :: Address Bar, task, P3)

Firefox 83
task
Points:
2

Tracking

()

RESOLVED FIXED
85 Branch
Tracking Status
firefox85 --- fixed

People

(Reporter: boontje, Assigned: mak)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Delete all search engines in "search shortcuts" field in about:preferences#search.

Actual results:

Unable to delete all, one search engine always remains...

Expected results:

Should allow deletion of all search shortcuts, because many users don't want the superfluous "search with Google" entry in the URL-bar suggestions when typing "w" or "g" in URL bar.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Search

Firefox requires at least one search engine to be enabled, it does not have to be Google, unless you want that as your default.

If you want to remove the "Search with Google" entry that is shown when you first click on the bar, you need to go to the new tab page (about:newtab), and unpin it from the top sites list:

https://support.mozilla.org/en-US/kb/customize-new-tab-page#w_customize-your-top-sites

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Component: Search → Address Bar
Resolution: --- → INVALID

(In reply to Dan from comment #0)

Should allow deletion of all search shortcuts, because many users don't want the superfluous "search with Google" entry in the URL-bar suggestions when typing "w" or "g" in URL bar.

Mark, I think this bug is referring to the new tab-to-search results. I'll change it a little.

Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Severity: -- → N/A
Type: defect → task
Points: --- → 2
Priority: -- → P3
Summary: unable to delete google in "search shortcuts". → Consider adding a pref to disable tab-to-search

(In reply to Harry Twyford [:harry] from comment #3)

(In reply to Dan from comment #0)

Should allow deletion of all search shortcuts, because many users don't want the superfluous "search with Google" entry in the URL-bar suggestions when typing "w" or "g" in URL bar.

Mark, I think this bug is referring to the new tab-to-search results. I'll change it a little.

Exactly... and I hereby express my deepest disagreement that it's currently not possible to disable that suggestion. (not even in about:config somewhere? Please tell me that there's some variable in about:config that we can disable it with.

I just checked, anyone knows why "browser.newtabpage.activity-stream.improvesearch.topSiteSearchShortcuts.havePinned"
has both entries "amazon,google" although I only have Google set to my shortcut engine? o_O

I was discussing briefly with Drew the heuristics for the result, it sounds like what we do, that is to adhere to autofill, doesn't work perfectly.
There are various options that we should discuss and brainstorm.
One possibility would be to have a sort of frecency for engines depending on how much they are used.
Another possibility may be, as a stopgap, to require at least 3 chars to be typed.
Another possibility may involve something similar to the one-off buttons checkboxes, where one can enable/disable tab-to-search on an engine basis, and with a per-result menu it would be possible to disable easily from the urlbar itself (so all engines would start as enabled, but the user could disable directly from the result menu).
We must talk about this.

Severity: N/A → S3
Summary: Consider adding a pref to disable tab-to-search → Consider adding a pref to disable tab-to-search or change its heuristic

(In reply to Dan from comment #4)

(not even in about:config somewhere? Please tell me that there's some variable in about:config that we can disable it with.

No, not currently. There's browser.urlbar.update2.tabToComplete but that pref is not supported and will be removed in bug 1665049. It's only there to roll this feature out.

I just checked, anyone knows why "browser.newtabpage.activity-stream.improvesearch.topSiteSearchShortcuts.havePinned"
has both entries "amazon,google" although I only have Google set to my shortcut engine? o_O

Those are your pinned Top Site search shortcuts on the new tab page. We pin Google and Amazon by default in some regions. You can unpin them by going to about:home.

(In reply to Harry Twyford [:harry] from comment #6)

(In reply to Dan from comment #4)

I just checked, anyone knows why "browser.newtabpage.activity-stream.improvesearch.topSiteSearchShortcuts.havePinned"
has both entries "amazon,google" although I only have Google set to my shortcut engine? o_O

Those are your pinned Top Site search shortcuts on the new tab page. We pin Google and Amazon by default in some regions. You can unpin them by going to about:home.

That appears to be inconsistent then aswell... currently, for me it says "amazon" in "browser.newtabpage.activity-stream.improvesearch.topSiteSearchShortcuts.havePinned".
But when checking about:home, I only see this.... https://i.postimg.cc/2zJ3xBGJ/about-home.jpg
So shouldn't the value field for that "...topSiteSearchShortcuts.havePinned" entry be empty then, instead of showing "amazon" ?

Flags: needinfo?(htwyford)

Looks like you hid the Top Sites from the new tab page. You can edit them by readding them with the gear icon on the new tab page.

Flags: needinfo?(htwyford)

Some experience here: I received a report from a user over IRC that he was confused why typing "y" made "search YouTube" appear in the Awesomebar and pushed the result he actually wanted down. Fiddling with Preferences->Search Suggestions didn't help. I (incorrectly) guessed this was related to search keywords, and went off on a wild goose chase, trying to find where we configure or store the key -> engine association.

I then asked on #firefox Slack, where after an hour of discussion, nobody had many any progress(!), until I found Harry in #search who explained how this works. (And it immediately make sense why typing "b" triggers Bugzilla for me, and not Bing...)

So right now this is a perfect storm of:
a) Feature that isn't very well known, even inside Mozilla, and not documented on SUMO (?).
b) No user-visible prefs to turn on/off (not counting about:config).
c) Clever heuristics that are not obvious at all, leading to confusion even if they work exactly as intended.

I'm sorry to hear that Gian-Carlo, but it doesn't represent the reality, and I'm surprised by what you say.
The feature has been in Nightly for a whole cycle, and in beta as well. We spoke about it at every firefox desktop meeting, and those notes made the Nightly Blog every 2 weeks. It was also in the Search status notes sent periodically by the Search program manager.

The heuristics were well known and accepted in the team, they work as intended for the most part, since I've seen a lot of happy reports from users who were waiting tab to search from a long time. Can it be improved? Of course it can, as pretty much everything, and that's what we will be discussing in the coming weeks. We will be measuring its impact on release through telemetry and an holdback study.

There's no pref because it was intended to be removed by removing the search engine (why keep an engine one doesn't want to search with?), or not presenting the search if that origin is not visited often.

We under-evaluated the case of quickly "type one or two letters, down, enter", for which I'm seeing some feedback we should address.

"I've seen a lot of happy reports from users who were waiting tab to search from a long time."

Do you mean "who were waiting for tab to search" or something else? (your sentence misses at least one word I think)

I, personally, am so frustrated of not having the ability to disable it, that I installed FF 82.0.3 alongside my 83 installation and started using 82.0.3.
I wondered if public statistics show how many other users did the same, so out of curiosity I visited https://data.firefox.com/dashboard/user-activity and voila, if I interpreted the data correctly, turns out quite less people are using FF 83 (62%) than they did all the way from FF 71 (!) up to 82 (~68%):
https://i.postimg.cc/sXBNh32r/FF83worrying-User-Decline-needs-Action-Asap.jpg

Please, realize the importance of adding a user-preference to disable this "feature".

(In reply to Dan from comment #11)

I, personally, am so frustrated of not having the ability to disable it, that I installed FF 82.0.3 alongside my 83 installation and started using 82.0.3.
I wondered if public statistics show how many other users did the same, so out of curiosity I visited https://data.firefox.com/dashboard/user-activity and voila, if I interpreted the data correctly, turns out quite less people are using FF 83 (62%) than they did all the way from FF 71 (!) up to 82 (~68%):
https://i.postimg.cc/sXBNh32r/FF83worrying-User-Decline-needs-Action-Asap.jpg

FF 83 has not been pushed out to everyone yet (we do limited speed roll-outs for the first few days as normal operation), and even when it does go to full speed, it takes a while to roll out to everyone.

The current plan is in bug 1681512 to allow the Search Preferences checkbox to not just hide the shortcut buttons at the bottom for an engine, but also to disable tab-to-search for that engine.
In this bug instead we plan to add a global toggle in the Address Bar preferences to provide or not tab to search results.

Edit: The overall result is that it will be possible to either disable this globally, or on a per-engine basis. It won't be possible to have tab to search but not one-offs or viceversa though.

Assignee: nobody → mak
Status: REOPENED → ASSIGNED
Summary: Consider adding a pref to disable tab-to-search or change its heuristic → Add a Preferences toggle for tab-to-search results
Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/128f96bf4414
Add a Preferences toggle for tab-to-search results. r=harry,fluent-reviewers,preferences-reviewers,flod
Status: ASSIGNED → RESOLVED
Closed: 4 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: