Tabsposé should only be tab-to-able when the OS is set to "All controls"

RESOLVED WONTFIX

Status

Camino Graveyard
Tabbed Browsing
--
minor
RESOLVED WONTFIX
8 years ago
8 years ago

People

(Reporter: Stuart Morgan, Assigned: Stuart Morgan)

Tracking

Trunk
All
Mac OS X

Details

(Assignee)

Description

8 years ago
It's odd to have Tabsposé be keyboard-enabled when nothing else is; we should be honoring the OS pref. I meant to do that, but it slipped my mind once I got it working in the All-controls case.

This wouldn't be a problem if we were using NSButtons, of course :P
Flags: camino2.0.1?
On a correctness level, I agree with you.

On the other hand, we enable tabbing to all controls inside the content area by default because people expect them to be tabable from the past and they're confused otherwise.  This isn't the content area, certainly, but it lives in the same place (and our other non-content area views that live where the content area does happen to be controls that are tabable by default [table and outline views]).

Also, I think once we ship 2.0 with it being tabable, it will be hard to undo without outcry.
(Assignee)

Comment 2

8 years ago
I think some kind of keyboard interface like I mentioned in the "Return" bug is a good idea, I just don't think we should use the keyboard-accessibility model (tab to select, control focus ring) for it.
Summary: Tabsposé should only be keyboard-selectable when the OS is set to "All controls" → Tabsposé should only be tab-to-able when the OS is set to "All controls"
(Assignee)

Comment 3

8 years ago
Hm, Finder does allow tab, so maybe if we do bug 524906 this should still be WONTFIX.
(Assignee)

Comment 4

8 years ago
Yeah, I don't think this is a good idea any more; we should just have a sexier selection effect and improve discoverability of keyboard navigation (bug 524906).
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: camino2.0.1?
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.