When the heuristic is hidden, include results that dupe it
Categories
(Firefox :: Address Bar, task, P2)
Tracking
()
People
(Reporter: adw, Assigned: adw)
References
Details
Attachments
(1 file)
When the heuristic is hidden, we shouldn't exclude results that dupe it.
I realized this while working on the top hit bug 1723160. I have nytimes.com in my profile with a very high frecency. When I enable the hideHeuristic pref, nytimes.com autofills but it doesn't appear anywhere in the results, which is confusing. After autofill, if I start to backspace over characters, then it appears as the top hit because when backspacing the heuristic becomes a search result.
| Assignee | ||
Comment 1•5 years ago
|
||
When the heuristic is hidden, we shouldn't exclude results that dupe it.
I realized this while working on the top hit bug 1723160. I have nytimes.com in
my profile with a very high frecency. When I enable the hideHeuristic pref,
nytimes.com autofills but it doesn't appear anywhere in the results, which is
confusing. After autofill, if I start to backspace over characters, then it
appears as the top hit because when backspacing the heuristic becomes a search
result.
There are three cases where we dedupe that currently depend on the heuristic and
therefore need to take into account when the heuristic is hidden:
- Autofill
- Prefix ranking/priority
- Search suggestions
The search suggestions case is maybe debatable. If you type "foo" and there's a
"foo" search suggestion but the heuristic is hidden, should we exclude the
suggestion? IMO we should include it because it may not be clear to the user
that pressing enter without selecting a result will perform a search for
"foo". It's better to let them see the result and select it. That means we may
end up pushing out the last search suggestion we would have otherwise shown, but
the last suggestion would have been pushed out anyway if the heuristic weren't
hidden, and IIRC we know that people rarely pick suggestions or results far down
the list anyway. In fact excluding the first suggestion probably excludes
exactly what they want to search for.
I've updated the relevant tests so they run some tasks with hideHeuristic
enabled.
I removed test_dupe_urls.js because I checked it to see if it needs updating and
it doesn't really do anything. It doesn't even call PlacesTestUtils.addVisits
correctly because it passes in two URLs, but addVisits only takes one
argument.
Comment 2•4 years ago
|
||
There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:adw, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•4 years ago
|
| Assignee | ||
Comment 3•4 years ago
|
||
I was waiting to land this until it was clear all the Firefox Suggest work was done for 92 and 93, which it is since yesterday. I'll land this on Monday.
| Assignee | ||
Comment 4•4 years ago
|
||
Comment 6•4 years ago
|
||
| bugherder | ||
Comment 7•4 years ago
|
||
Hey Drew,
Could you please help me with some steps to reproduce and confirm the fix (if it's doable)?
| Assignee | ||
Comment 8•4 years ago
|
||
Hi Cristian, sorry for the huge delay, I'm really behind on my needinfos. Thanks for trying to verify this.
STR:
- Set
browser.urlbar.experimental.hideHeuristic=true - Type www.nytimes.com in the urlbar and hit enter
- Start typing www.nytimes.com again, it should autofill
- Verify that the first result in the Firefox Suggest group (i.e., in the bookmarks/history results) is www.nytimes.com
The fact that nytimes.com did not appear in the results is what this bug is about.
Comment 9•4 years ago
|
||
The issue is verified fixed using the steps provided in comment 8 in Fx95.0b10 and latest Fx96.0a1 on Windows 10, macOS 11.5 and Ubuntu 20.04. The result is correctly displayed in the Firefox Suggest section.
Description
•