Mozilla doesn't obey OS settings for tabbing in UI controls

RESOLVED EXPIRED

Status

SeaMonkey
Themes
--
minor
RESOLVED EXPIRED
16 years ago
8 years ago

People

(Reporter: Matthew Paul Thomas, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
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

16 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

16 years ago
I thought the plan was that linux would get the same defaults as Mac ... just
form nav by default ...?
(Reporter)

Comment 3

16 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

15 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

9 years ago
Product: Core → SeaMonkey
Assignee: shliang → nobody
Priority: P4 → --
QA Contact: pmac → themes
Target Milestone: mozilla1.2alpha → ---

Comment 5

9 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

8 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
Last Resolved: 8 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.