No way to keyboard navigate back to the about:preferences page nav from the findInPage pane
Categories
(Firefox :: Settings UI, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox154 | --- | fixed |
People
(Reporter: hjones, Assigned: tgiles)
References
(Blocks 1 open bug)
Details
(Whiteboard: [recomp])
Attachments
(1 file)
When you search for something in preferences it takes you to a distinct pane to display the search results. When you're on this pane no button in the moz-page-nav is highlighted, so there's no way to keyboard navigate back to it to change the page. We fixed this for all the other panes in Bug 2038759, but it wasn't clear how this should work for findInPane - which sidebar button should stay highlighted? This is a preexisting issue in the old settings UI.
Updated•3 months ago
|
Comment 1•3 months ago
|
||
Recommended solution:
- add "Back" option when viewing search results (similar to subpage headers)
- closing the search ("x" in search bar) returns user to the pane and scroll position they were on
Not a redesign release blocker
| Assignee | ||
Updated•2 months ago
|
| Assignee | ||
Comment 2•2 months ago
|
||
When searching in about:preferences, paneSearchResults is a virtual
category with no matching moz-page-nav-button. Because the nav is
declared allownoselect="true", every button gets tabindex=-1 when
that view is active, leaving no keyboard tab stop into the category
list.
Adds a standalone ghost moz-button "Back" affordance as the first child
of #header-searchResults. The header is always visible when a query is
active, so the button covers both the results and no-results cases.
Activating it reuses the existing search dismiss path in findInPage.js
and then focuses the now-selected moz-page-nav-button, landing the user
directly in the category list. The selected nav button is determined
from categories.currentView after navigation, so the behavior is
correct in the legacy and redesign-enabled cases.
Comment 4•2 months ago
|
||
| bugherder | ||
Description
•