333513 - Prevent tab bar from gaining focus on Mac OS X when Full Keyboard Access is disabled in the OS

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Joe Hughes]

Currently, when the user clicks on the active tab in Mac OS X, a focus ring gets applied to the tab, even if Full Keyboard Access is disabled.

Comment 1

[Jesse Ruderman]

IMO, clicking the active tab shouldn't focus the tab bar, regardless of whether Full Keyboard Access is enabled.  I focus the tab bar accidentally in this way at least once a week, and then I'm surprised when my attempts to scroll cause me to switch tabs.

Comment 2

[Håkan Waara]

*Clicking* a tab shouldn't focus it, however tabbing to it should focus it regardless whether that Mac OS X pref is on. 

How else do you know where you are in the tabbing cycle?

Comment 3

[Jesse Ruderman]

When Full Keyboard Access is disabled, Tab should probably skip the tab bar.  I don't think anyone is asking for it to get focus invisibly :)

Comment 4

[Jesse Ruderman]

hwaara and I discussed this a bit on IRC.  We concluded that there are two bugs:

(1) on Mac, with FKA turned off, the tab bar shouldn't be in the tab order

(2) on all platforms, clicking the active tab shouldn't focus the tab bar

I'm morphing this slightly to cover (2), since just fixing (1) wouldn't help with the reporter's complaint or my unhappiness.

Comment 5

[Mark Pilgrim (inactive)]

(In reply to comment #4)
> (1) on Mac, with FKA turned off, the tab bar shouldn't be in the tab order

Agree.

> (2) on all platforms, clicking the active tab shouldn't focus the tab bar

Disagree strongly.  At least on Windows, clicking the active tab should set focus.  See, for example, the Accessibility Options control panel.

Comment 6

[Håkan Waara]

(In reply to comment #5)
> > (2) on all platforms, clicking the active tab shouldn't focus the tab bar
> 
> Disagree strongly.  At least on Windows, clicking the active tab should set
> focus.  See, for example, the Accessibility Options control panel.

If someone clicks a tab, that usually means "show the page for this tab". Safari does this, Camino does this.  Maybe it's a mac-specific expectation - who knows? :)

But I think the tab bar in itself should be invisible to the user, and not steal focus on clicks. Having it be tabbable-to makes sense though.

Unfortunately, I don't have a windows box, so I can't check the a11y options control panel.

Comment 7

[Mark Pilgrim (inactive)]

(In reply to comment #6)
> If someone clicks a tab, that usually means "show the page for this tab".
> Safari does this, Camino does this.  Maybe it's a mac-specific expectation -
> who knows? :)

Yes, fine, on the Mac we are all agreed that clicking a tab should bring the tab to the front without setting focus to the tab itself.  Unless -- possibly -- the "Full Keyboard Access" option in the Keyboard Shortcuts tab of the Keyboard & Mouse control panel is set to "All controls".  (Note that Safari does not respect this option.)

My point is that this is a platform-specific expectation.

> But I think the tab bar in itself should be invisible to the user, and not
> steal focus on clicks. Having it be tabbable-to makes sense though.

That makes no sense at all.  A tab doesn't "steal" focus on clicks.  You're the one who clicked it!  And having a control that receives focus through tabbing but doesn't receive focus when you click it... that's just weird.

> Unfortunately, I don't have a windows box, so I can't check the a11y options
> control panel.

Well, it's the same in every control panel, as well as every application that uses the standard Windows tab control.

Comment 8

[Jesse Ruderman]

I think it's worth breaking with the standard Windows control's behavior, and breaking with the "if it's focusable, clicking it should focus it" guideline, because 

(1) the number of users who accidentally focus the tab bar in this way is much bigger than the number of users who intentionally focus the tab bar in this way.

(2) the shortcuts that are active while the tab bar has focus conflict with basic keyboard commands such as scrolling.

(3) consistency with other web browsers is important, too.

Comment 9

[Håkan Waara]

Note that Safari does respect the FKA preference, and when it is on, lets you focus tabs.  However, only using the keyboard (it's a keyboard pref after all).

Comment 10

[Joe Hughes]

I'm sorry, Jesse, but I think that you hijacked my bug here.  I don't want the simple Mac OS X issue that I opened it about to get lost in debate about the cross-platform focusability of the tab bar.

What this bug is about:
(1) On Mac OS X, clicking the active browser tab shouldn't give focus to the tab
(2) On Mac OS X, the browser tabs should only be in the tab order if Full Keyboard Access is enabled

Comment 11

[Mark Pilgrim (inactive)]

(In reply to comment #9)
> Note that Safari does respect the FKA preference, and when it is on, lets you
> focus tabs.  However, only using the keyboard (it's a keyboard pref after all).

Well, this is inconsistent with other Apple applications such as iPhoto, which (AFAICT) uses the standard OS X widget for tab controls.  This widget *does* focus a tab when you click it (and FKA is on).  See, for example, the Photo Info dialog (cmd-I) in iPhoto.  This is true even when the tab panel contains focusable controls; see for example the Keywords tab of iPhoto's Photo Info dialog.

Bottom line: we can point to different applications on the platform (all from Apple, no less!) to support our different viewpoints.  The "standard" behavior, such as it is on OS X, is:

- if FKA is on, tabs should be able to receive focus via keyboard *or* mouse click.
- if FKA is off, tabs should never receive focus.  They are not in the tab order and they respond to clicks merely by selecting their panel.

(Note that you may need to restart an application after changing the FKA system preference in order to see the change.)

Comment 12

[Joe Hughes]

Mark, I looked at the Photo Info dialog in iPhoto (6.0.2), and if you have the Keywords tab active, and a checkbox focused (and Full Keyboard Access enabled), clicking on the tab doesn't seem to move the focus from the widget to the tab.

Comment 13

[Håkan Waara]

(In reply to comment #11)
> (In reply to comment #9)
> > Note that Safari does respect the FKA preference, and when it is on, lets you
> > focus tabs.  However, only using the keyboard (it's a keyboard pref after all).
> 
> Well, this is inconsistent with other Apple applications such as iPhoto, which
> (AFAICT) uses the standard OS X widget for tab controls. 

I'm sorry, I still disagree.  The tab widget you are referring to is one that is entirely different from the one in our browser -- both in how it looks, and in how it is used.

The only apps I know that have a tab widget corresponding to ours are Adium, Colloquy and Camino. This widget seems to be spreading across the mac community. The primary reason it has been reinvented, is actually because Apple has no such widget in its toolkit.

> 
> Bottom line: we can point to different applications on the platform (all from
> Apple, no less!) to support our different viewpoints. 

Yes, wasn't as simple as we first thought. ;-) 

I'm mostly arguing from the viewpoint of consistency with the system though, and there I simply see this behavior as "weird".  I'm not sure why it would increase accessibility either, when the bug is only about its click behavior.

> The "standard" behavior,
> such as it is on OS X, is:
> 
> - if FKA is on, tabs should be able to receive focus via keyboard *or* mouse
> click.

What I don't understand is the extrapolation where you want "Full _Keyboard_ Access" to mean that also clicking it with the mouse should focus it?

Like I said, my primary concern is that this behavior is mostly inconsistent with every other mac app that use tab widgets such as ours.  If we used the standard tab widget, it would be another story.  

I'm also not really convinced of the benefit of making tabs focusable with the mouse?

Comment 14

[Jesse Ruderman]

I filed bug 462289 on the cross-platform bit: "Clicking the selected tab should not focus the tab bar".

Comment 15

[Dão Gottwald [:dao]]

(In reply to comment #11)
> - if FKA is on, tabs should be able to receive focus via keyboard *or* mouse
> click.

Why? We have a bunch of keyboard shortcuts for the tab bar, none of which require focus.

Comment 16

[Robert Strong (they/them - no direct email)]

Not a shell integration bug... moving to tabbed browser since bug 462289 is against tabbed browser though that may be incorrect... hopefully this won't stagnate there too.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Hasn't this been fixed with Firefox 3.6? When tabbing through the whole interface I never see the focus placed on the tabbar or any tab, whether if FKA is enabled or not. Jesse, can you please check? Thanks.

Comment 18

[Jesse Ruderman]

On trunk, I can focus the tab bar with the Tab key only if FKA is enabled.  I think that's the desired behavior.  (I have to open a new Firefox window for changes to the systemwide FKA pref to take effect.)

Comment 19

[Henrik Skupin [:whimboo][⌚️UTC+1]]

You can also hit Ctrl+F7. With that shortcut the FKA is immediately obeyed. And yes, with FKA disabled only text boxes and lists are getting focused. So I think we can mark this bug as WFM.