Closed
Bug 122624
Opened 23 years ago
Closed 14 years ago
Mozilla doesn't obey OS settings for tabbing in UI controls
Categories
(SeaMonkey :: Themes, defect)
SeaMonkey
Themes
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: mpt, Unassigned)
References
()
Details
Currently Mac Classic is hard-coded for Tab/Shift+Tab to navigate between text fields and listboxes, while Modern is hard-coded for Tab/Shift+Tab to navigate between all controls. Focusability of controls on other themes seems to depend on which platform was used by the person creating the theme. This is wrong. Focusability of controls should be platform-specific, not theme-specific. In particular, Mozilla on Mac OS X should follow the OS pref for whether controls have default keyboard access (Tab/Shift+Tab goes between text fields and listboxes only) or full keyboard access (Tab/Shift+Tab goes between all controls). (By default, this pref is toggled by typing Ctrl+F1.) As far as I can tell, this will involve: (1) checking the OS pref at startup, and setting focusability accordingly; (2) listening for changes in the pref while Mozilla is running, and setting focusability accordingly (including properly handling the edge case where focus is on a non-field control at the moment when the mode is changed from full keyboard access to default keyboard access); (3) responding to the keyboard shortcut (which is user-configurable, but Ctrl+F7 by default) to temporarily switch the keyboard access mode in an individual window. I'm marking this All/All because (a) the fact that focusability is theme- specific rather than platform-specific is a bug on all platforms, not just OS X, and (b) I think the option should be implemented as a hidden pref on all platforms, and change depending on the OS setting on OS X (in the same way as platform-specific Editor behaviors are implemented using hidden prefs).
Comment 1•23 years ago
|
||
I agree. Thanks for filing the bug. I won't be able to get to it right away, but we need to be able to switch between form nav and form+link nav. The default should fit the platform -- Mac is the only platform I know of that should default to forms only.
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → mozilla1.2
Comment 2•23 years ago
|
||
I thought the plan was that linux would get the same defaults as Mac ... just form nav by default ...?
Reporter | ||
Comment 3•23 years ago
|
||
You are both confusing this bug with bug 66285, which is about what elements should be focused when tabbing through HTML. This bug is *not* about HTML, it's about XUL. Navigating through HTML is an app-specific pref; navigating through the GUI is an OS-global pref.
Comment 4•22 years ago
|
||
Okay, so as mpt says this isn't just about whether to tab to links. This is an OS setting that says either 1. textboxes and listboxes only or 2. all form controls.
Assignee: aaronl → shliang
Status: ASSIGNED → NEW
Component: Keyboard Navigation → Themes
QA Contact: sairuh → pmac
Summary: Mozilla doesn't obey OS settings for Default/Full Keyboard Access → Mozilla doesn't obey OS settings for tabbing in UI controls
Assignee | ||
Updated•16 years ago
|
Product: Core → SeaMonkey
Updated•16 years ago
|
Assignee: shliang → nobody
Priority: P4 → --
QA Contact: pmac → themes
Target Milestone: mozilla1.2alpha → ---
Comment 5•15 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Comment 6•14 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•