Consider tweaking tab navigation behavior on macOS
Categories
(Core :: DOM: UI Events & Focus Handling, enhancement, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox128 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
Details
Attachments
(2 files)
(In reply to Neil Deakin from bug 1036966 comment #32)
From reading the patch and checkin comment, it appears to make tab navigation worse. It seems to remove support for the full keyboard access setting and force you to use some other UI to change this. In addition, the Ctrl+F7 keyboard shortcut can no longer be used to switch full keyboard access off and on, meaning I have to choose either to suffer the tab navigation model other platforms use, or one where I cannot focus all items when I need to, I can't toggle it quickly or use the Option key method as Safari does. (I realize of course that accessibility users would need to navigate between all elements).
But maybe I misinterpreted the intent here?
I would recommend closing this bug as wontfix and implementing a behaviour closer to what Safari has done where Tab can be used to cycle between textboxes and lists (and possibly some other things) and Option+Tab can be used to cycle between all elements. Personally, I would remove the special preference UI and just have that the behaviour for all content and chrome UI and the full keyboard access setting can be used to flip the Tab and Option+Tab behaviour around.
Some of this seems reasonable. I think keeping the default tab navigation focusing all elements makes sense, but maybe:
-
Full keyboard access / the OS keyboard navigation setting could/should override our checkbox. Maybe we should reword a bit the settings checkbox if we do this but that seems maybe trivial and would address a good part of Neil's concern.
-
Force Option+Tab to focus all elements. I think that's also a nice thing to do.
Comment 1•1 year ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #0)
- Full keyboard access / the OS keyboard navigation setting could/should override our checkbox.
So the OS setting would override when the checkbox is checked or unchecked? If it overrides when checked, that takes us back to where we were, since the OS default is the focus-only-some elements behaviour. If you mean when unchecked, this was Morgan's original intent: to make it so that disabling the setting reverted to the OS setting. I understand why that could create it's own confusion, though.
| Assignee | ||
Comment 2•1 year ago
|
||
When unchecked, of course, sorry
| Assignee | ||
Comment 3•1 year ago
|
||
Maybe we should tweak the wording of the settings checkbox to more
strongly not implying that having it un-checked will not go through
links, but I'm not sure what wording could be best there.
Updated•1 year ago
|
| Assignee | ||
Comment 4•1 year ago
|
||
Also, remove the applies_to_xul pref. On Windows / Linux it does
nothing by default effectively, and on macOS its purpose is quite
limited too since it's true by default.
| Assignee | ||
Comment 5•1 year ago
|
||
Comment 4 needs tests, but I'm assuming that something like it is what you were describing, is that right? With these patches, the Firefox behavior with the settings checkbox unchecked should be exactly what you want, and the only difference is the default focus model (which would match other platforms).
Comment 7•1 year ago
|
||
| bugherder | ||
Updated•1 year ago
|
Updated•1 year ago
|
Description
•