Closed Bug 1672507 Opened 4 months ago Closed 1 month ago

History is not shown in search mode when general results are set to come before search results

Categories

(Firefox :: Address Bar, defect, P2)

Firefox 83
defect
Points:
3

Tracking

()

VERIFIED FIXED
86 Branch
Iteration:
86.3 - Jan 11 - Jan 24
Tracking Status
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- verified

People

(Reporter: lucas.werkmeister, Assigned: mak)

References

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Type w wa into the awesome bar, where w is a search shortcut for Wikipedia.

Actual results:

The awesome bar suggests various searches with “wa” I did in the past.

Expected results:

The first suggestion should be the watchlist (https://en.wikipedia.org/wiki/Special:Watchlist), as the most relevant “wa” history result on Wikipedia (I frequently visit it), even though it’s not a regular search result. I used to rely on this to quickly navigate to my watchlists on various wikis, but with Firefox 82, search keywords are apparently handled differently and history suggestions are no longer brought up.

Version: Firefox 82 → Firefox 83

I used to rely on this to quickly navigate to my watchlists on various wikis, but with Firefox 82, search keywords are apparently handled differently and history suggestions are no longer brought up.

Make that Firefox 83, sorry. Mixed up my versions.

I'm still getting as a first suggestion the "watchlist" when I type "w wa" in the Url bar - tested on Mac OS X 10.15 (logged into Wikipedia, set the w keyword on Firefox 82.0.2 and opened the same profile with Firefox 83 beta 10). I'm going to assign a component for this so that someone with more knowledge in this area can take a look over.

Component: Untriaged → Address Bar

Did you set w as the alias for Wikipedia in about:preferences#search, or is it a bookmark keyword?

Flags: needinfo?(lucas.werkmeister)

The about:preferences#search kind. (I didn’t even know about bookmark keywords until a few weeks ago.)

Flags: needinfo?(lucas.werkmeister)

Interesting. It's expected in 83 that typing a search engine keyword followed by a space should enter that engine's "search mode" indicated by a blue indicator in the Urlbar with the engine's name. In Wikipedia's case, you should be seeing both suggestions from Wikipedia and your most relevant Wikipedia history. Do you see this? If not, can you please attach a screenshot of what it looks like when you type w wa?

Flags: needinfo?(lucas.werkmeister)

Well, my dropdown is just completely filled with search suggestions. (If I type the w wa very quickly, I can actually see history results for a moment, but the search suggestions come up remarkably fast.) I’m curious what you see – are search suggestions intermingled with history results, or do you have less suggestions?

Flags: needinfo?(lucas.werkmeister)

To be fair – the search suggestions seem to take into account my search history as well, so by now it’s learning to “Special:Watchlist” as the first search term (though curiously it takes a brief moment to appear, after the search suggestions have already loaded), which I can live with a bit better. But still, not every possible history suggestion I might need can be recreated as a search suggestion.

I should maybe clarify that I tried to “streamline” the description a bit – in reality, my w searches German Wikipedia, and English Wikipedia is enw. And the Watchlist I most often need is the Wikidata one, shortcut wd. So the first screenshot (previous comment) is for enw, where Firefox hasn’t yet learned to suggest Special:Watchlist; the second one (this comment) is for wd, where Special:Watchlist is now coming up. (Interestingly, this one also has more history search results rather than search suggestions…?)

I also just recorded a screencast of typing com wa, for Wikimedia Commons – possibly the best showcase of this bug, since here Firefox also learned to suggest Special:Watchlist as a search but (unlike Wikidata, apparently) still has a lot of search suggestions that “crowd out” the history results, leading to a kind of combination of the two screenshots above. I think the video shows a bit too much of my browsing history to be comfortable posting it publicly, but I’ll be happy to send it to you or other Mozilla folks via email or something.

I can reproduce the issue when "Show search suggestions ahead of browsing history in address bar results" is unchecked. That pref is in about:preferences#search. History shows up in search mode when that box is checked. Is that box unchecked on your profile?

We'll try to get this fixed for 84.

[Tracking Requested - why for this release]:
Regression introduced by Urlbar update 2. We're trying to fix most of those regressions in 84.

(In reply to Lucas Werkmeister from comment #7)

wd, where Special:Watchlist is now coming up. (Interestingly, this one also has more history search results rather than search suggestions…?)

The majority of third-party engines, like the one you added for Wikidata, don't offer search suggestions. We show search history and history results instead. The built-in Wikipedia engines support search suggestions, so they show up for those searches.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Points: --- → 3
Ever confirmed: true
Keywords: regression
Priority: -- → P2
Summary: Search keywords no longer bring up history suggestions in awesome bar → History is not shown in search mode when general results are set to come before search results

In search mode search suggestions always come before history results, by our design choice.
it's possible there's some bug with the limits, but I'm not sure if we discussed which limits to use there at all.
Thus, I'm not sure this is a regression, indeed I'd not be able to tell what would have regressed here, we didn't have Search mode before, so we can't compare.

Keywords: regression

I'm clearing tracking until we discuss this.

I can reproduce the issue when "Show search suggestions ahead of browsing history in address bar results" is unchecked. That pref is in about:preferences#search. History shows up in search mode when that box is checked. Is that box unchecked on your profile?

It’s unchecked, and also disabled, apparently because “Show search suggestions in address bar results” is unchecked. (If I check that, “Show suggestions ahead…” becomes enabled.)

In case it matters, I have “Add search bar in toolbar”, rather than “Use the address bar for search and navigation”, but the issues I’m reporting here happen when using the address bar, not the search bar.

Iteration: --- → 86.3 - Jan 11 - Jan 24
Assignee: nobody → mak
Status: NEW → ASSIGNED

When the user unchecks the "Show search suggestions before history results" pref,
we change browser.urlbar.matchBuckets to general:5;suggestions:Infinity.
When the code inverted the buckets, it put Infinity suggestions before general
results, pushing them away.
That pref could also be modified by the users or an experiment, so we can't just
set a suggestions limit from the default value (4 at this time).
The safest solution seems to be to get the results, then transplant suggestions
at the top, that allows to keep the matchBuckets defined number of general
results and fill remaining space above them with suggestions.

Pushed by mak77@bonardo.net:
https://hg.mozilla.org/integration/autoland/rev/2fa0ce53d3df
History results are not shown in search mode when they are set to come before search suggestions. r=harry
Status: ASSIGNED → RESOLVED
Closed: 1 month ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

I don't think this is critical enough to be worth an uplift at this point.

I reproduced this issue on Ubuntu 20.04 LTS using Fx 83.0.
I can confirm this issue is fixed, I verified on Windows 10 x64, macOS 10.13 and Ubuntu 20.04 using Fx 86.0.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.