Show suggestions for the empty query when in search mode
Categories
(Firefox :: Address Bar, enhancement, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | verified |
People
(Reporter: bugzilla, Assigned: mak)
References
Details
Attachments
(3 files, 1 obsolete file)
We should show suggestions when the input is empty but the user is in search mode. A user might get in this scenario by selecting a one-off with an empty input or when pressing Accel+K.
Product would like us to look into showing trending searches, but this will require collaboration with Google and some UX work. In the meantime, we can show maxRichResults
form history results. This could also be what we show for non-Google engines.
We should only show form history for searches made with the current search mode engine.
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Currently form history is per input field, not per engine, so this apparently requires redesigning form history, that is quite expensive.
Assignee | ||
Comment 2•4 years ago
|
||
A possible workaround here may be on search store form history both in searchbar-history and in searchbar-history-engineName, then use the latter for empty searches, while the former will continue ensuring search history is shared across fields. In the future if we want to completely sandbox search history we can just stop using the old one.
Assignee | ||
Comment 3•4 years ago
|
||
another alternative may be to modify FormHistory to get an optional descriptor object when it's updated, containing whatever we want. New versions could know how to retried and parse that, while old versions would ignore it. This may be a bit more complex to implement (schema migration and filtering in the search controller), but likely would be more future proof.
Assignee | ||
Comment 4•4 years ago
|
||
It sounds like I just volunteered to pick this.
Comment 5•4 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #3)
another alternative may be to modify FormHistory to get an optional descriptor object when it's updated, containing whatever we want.
I vote for this fwiw. :-) But maybe we shouldn't try to overgeneralize -- just store the engine instead of a general object?
Also, addressing the other part of this, form history has its own frecency and we could sort by that and show the top maxRichResults
(for the given engine).
Assignee | ||
Comment 6•4 years ago
|
||
(In reply to Drew Willcoxon :adw from comment #5)
(In reply to Marco Bonardo [:mak] from comment #3)
another alternative may be to modify FormHistory to get an optional descriptor object when it's updated, containing whatever we want.
I vote for this fwiw. :-) But maybe we shouldn't try to overgeneralize -- just store the engine instead of a general object?
I'm actually adding a moz_sources table that can contain strings, the string can be the engine name of course. This stays "searchable".
Also, addressing the other part of this, form history has its own frecency and we could sort by that and show the top
maxRichResults
(for the given engine).
I think that already happens automatically, but anyway I agree.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 7•4 years ago
|
||
Add an optional source property for FormHistory that can be defined when bumping,
removing of querying values.
This can be used by consumers to partition FormHistory based on specific sources,
for example the name of the engine used to execute the search.
Comment 8•4 years ago
|
||
Comment on attachment 9167176 [details]
Bug 1654862 - Show suggestions for the empty query when in search mode. r=adw
Revision D85489 was moved to bug 1656348. Setting attachment 9167176 [details] to obsolete.
Assignee | ||
Comment 9•4 years ago
|
||
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
Depends on D86355
Assignee | ||
Comment 11•4 years ago
|
||
Depends on D86386
Comment 12•4 years ago
|
||
Comment 13•4 years ago
|
||
I autolanded the first two patches since Marco will be away for a bit; adding leave-open until part 3 lands.
Comment 14•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 15•4 years ago
|
||
Comment 16•4 years ago
|
||
bugherder |
Comment 17•4 years ago
|
||
I verified this issue using 82.0a1 (2020-09-14) on macOS 10.13 and Windows 10 x64.
Adrian could you help me with Ubuntu verification?
Comment 18•4 years ago
|
||
Verified as fixed under Ubuntu 18.04 64-bit using Firefox 81RC (with update2 prefs enabled) and latest Nightly 82.0a1.
Description
•