When using one-off search buttons from the keyboard, there's no way to distinguish engines with the same icon
Categories
(Firefox :: Address Bar, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox70 | --- | wontfix |
firefox71 | --- | wontfix |
firefox72 | --- | verified |
People
(Reporter: florian, Assigned: mak)
References
(Regression)
Details
(Keywords: access, regression, Whiteboard: [access-p2])
Attachments
(2 files)
Bug 1561894 removed the name of the selected one off search engine from the UI. If I have Wikipedia in multiple languages, there's no way to know which one I'm picking using the keyboard, I have to use the mouse to hover the icon.
Reporter | ||
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 2•5 years ago
|
||
For the search bar we can likely use the header to show the currently selected one-off name.
For the urlbar, if a search result is selected it has a "- Search with <Engine>" suffix, that changes when selecting different one-offs. So the problem seems to only affect url results, and I'm not sure that's a critical problem because it's less likely to search for urls.
If we'd fix the search bar, this bug would probably be less critical.
Thoughts?
Reporter | ||
Comment 3•5 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #2)
For the search bar we can likely use the header to show the currently selected one-off name.
That would work; but what was wrong with the previous solution (ie changing the string displayed above the set of one-off buttons) ?
For the urlbar, if a search result is selected it has a "- Search with <Engine>" suffix, that changes when selecting different one-offs.
That suffix gets hidden as soon as the row is no longer selected, so it's hidden when selecting a one-off. Also, selecting one-offs from the keyboard in the urlbar seems pretty difficult. The only way I found is to press the down arrow several times to go through all the suggestions and history results.
Assignee | ||
Comment 4•5 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #3)
(In reply to Marco Bonardo [:mak] from comment #2)
For the search bar we can likely use the header to show the currently selected one-off name.
That would work; but what was wrong with the previous solution (ie changing the string displayed above the set of one-off buttons) ?ù
It was a purely UX decision.
In the urlbar it's no more above the buttons, it's inline now; it would move the buttons around if we'd update the string.
The searchbar just followed to simplify the implementation and maintenance, and it's the place where we can easily fix this problem because it still has the header. The search bar is not our primary target anyway, its usage is declining constantly.
For the urlbar, if a search result is selected it has a "- Search with <Engine>" suffix, that changes when selecting different one-offs.
That suffix gets hidden as soon as the row is no longer selected, so it's hidden when selecting a one-off.
yes, selecting with up, down has that problem, selecting with ALT+DOWN/UP doesn't. We could evaluate to keep the "search with" text in the first result if a one-off button is selected.
Also, selecting one-offs from the keyboard in the urlbar seems pretty difficult. The only way I found is to press the down arrow several times to go through all the suggestions and history results.
ALT+DOWN or just UP should work, the former is totally undiscoverable though.
There's Bug 1437524 where we discussed about the possibility to use TAB to toggle between one-off buttons and results, but there's some resistance against such a change, because Chrome also supports TAB to move through results.
We also have a new Search button, under design now, that maybe could help a bit here, but we really need UX brainstorming about all the discoverability and navigation problem of one-off buttons.
In the meanwhile we can fix the search bar and urlbar with the above suggestions:
- use the header in the search bar
- don't hide the "- Search with" suffix if a one-off is selected
Reporter | ||
Comment 5•5 years ago
|
||
(In reply to Marco Bonardo [:mak] from comment #4)
ALT+DOWN or just UP should work, the former is totally undiscoverable though.
I actually didn't know about it! I thought ALT+up/down changed the default engine.
In the meanwhile we can fix the search bar and urlbar with the above suggestions:
- use the header in the search bar
- don't hide the "- Search with" suffix if a one-off is selected
Yeah, I think that would work and provide a consistent user experience.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 6•5 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #5)
ALT+DOWN or just UP should work, the former is totally undiscoverable though.
I actually didn't know about it! I thought ALT+up/down changed the default engine.
That only happens in the search bar with CTRL+UP/DOWN and imo it's not great, it's another undiscoverable feature that moreover changes things permanently. We don't plan to port that to the urlbar, afaik.
Clearing ni on Verdi, we have a way out for now, the global design and search button is something he is already brainstorming.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 7•5 years ago
|
||
Show the selected one-off button engine in the searchbar header.
Assignee | ||
Comment 8•5 years ago
|
||
When a one-off button is the only selection, and the heuristic result is the
a search, forcibly show its action text, so the search engine name is visible.
This doesn't handle cases where the heuristic results are not searches, because
it would be a lot more complex and involve heavy design changes. Those cases
should be less common, representing searches for urls or non-search strings on
other engines.
Depends on D53784
Comment 10•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7f80960886b9
https://hg.mozilla.org/mozilla-central/rev/44bb8023055c
Comment 11•5 years ago
|
||
We're building the final Fx71 beta before next week's RC tomorrow (Thursday). Is this something we should consider uplifting at this point in the cycle?
Assignee | ||
Comment 12•5 years ago
|
||
The timeline looks a bit strict, the patch is not particularly scary but I couldn't check it before tomorrow.
I don't think the bug is particularly critical, it's surely an annoyance, but doesn't really break functionality.
Comment 13•5 years ago
|
||
We have shipped our last beta for 71, since we have a patch in 72, I am setting 71 as fix-optional in case a safe fix could be uplifted as a ridealong in a dot release.
Updated•5 years ago
|
Comment 14•5 years ago
|
||
I reproduced this issue using Fx 72.0a1 (2019-10-22), on Windows 10 x64.
I can confirm this issue is fixed. I verified using Fx 73.0a1 and Fx 72.0b11, on Windows 10 x64, Ubuntu 18.04 LTS and macOS 10.13.6.
Updated•3 years ago
|
Description
•