Previously a reasonable number of users have complained about not being able to tab to drop down boxes in web forms with Firefox (bug 350145, bug 396857, bug 408908, and 3% of responses to cbarrett's post on how to improve Firefox on OS X). It appears that we are honoring a setting in the OS X keyboard and mouse preferences to only tab between text fields and list boxes (see attachment for pref, implementation was done in bug 187508). This default behavior is rather annoying and users cannot be expected to figure out that the problem is a poorly chosen OS default setting as opposed to a bug in Firefox. As additional rationale, Safari 3.1 even ignores the setting and allows user's to tab to drop down boxes. The tabbing behavior appears to be controlled by the pref Accessibility.tabfocus: http://kb.mozillazine.org/Accessibility.tabfocus I recommend that we set this pref to a default value of 3 regardless of the OS setting, since this is the most logical behavior.

Bug 437296 has been filed to change the default behavior.

Disregard comment #1, it also looks like the pref Accessibility.tabfocus no longer exists.

Thinking about this a little more, how about we interpret the system pref differently. "Text boxes and lists" should really map to "Text boxes, list boxes, and drop down lists" since list boxes and drop down lists are really both forms of "lists." I think we took the pref a little too literally in bug 187508.

(In reply to comment #3) > it also looks like the pref Accessibility.tabfocus no longer exists. The pref accessibility.tabfocus most definitely exists, but it's not set on the Mac; this makes the look and feel code fall default to the OS setting.

>The pref accessibility.tabfocus most definitely exists, but it's not set on the >Mac; this makes the look and feel code fall default to the OS setting. ok, so it just isn't exposed in about:config? Either way a setting of 3 potentially picks up more than we want (like checkboxes and radio buttons).

Since Safari has been cited as a precedent, a little detail: The Safari behavior was changed in 1.3 (for Mac OS X 10.3) and 2.0 (for 10.4), which were released simultaneously. In Safari 1.2, with Full Keyboard Access turned off and Safari's own "Press Tab to highlight each item on a webpage [sic]" checkbox also unchecked, Tab focused only text fields and list boxes. In 1.3 and 2.0, the same combination of settings also focused option menus. Regardless of version, turning on Full Keyboard Access makes all other form controls tabbable, and turning on Safari's own "Press Tab to highlight each item on a webpage" preference makes all form controls *and* all links tabbable. Mac OS X 10.3 was the only version of OS X for which Full Keyboard Access was a checkbox, rather than a pair of radio buttons. This made it non-obvious exactly which controls should be Tabbable when it was unchecked. But in 10.1, 10.2, 10.4, and 10.5, the radio buttons make it clear that Safari is not doing the standard thing: it's focusing option menus when no other application does (and when even Safari doesn't, outside of Web pages). One way of avoiding the same problem in Firefox would be to offer a four-way preference that explicitly overrides the system settings: "Text fields and lists", "Text fields, lists, and menus", "All controls", and "All controls and links". Any Mozillan who knows me knows that I loathe adding preferences, but I don't see a better way of getting out of the quandary that System Preferences has put you in.

(In reply to comment #4) > Thinking about this a little more, how about we interpret the system pref > differently. "Text boxes and lists" should really map to "Text boxes, list We could do that, but it would be inconsistent with how OSX interprets it, so I'm not sure that would be functionally any different from just ignoring that setting :) If we believe that there's no good reason for tab to skip over those controls, we should just ignore the OS setting. If we believe that this is really something that OSX users feel strongly about ("omg, drop-downs, ew!" ?) then we need to continue to observe it. I, too, am loathe to add preferences, and think that the confusion introduced by Safari's override of this pref is a little bizarre.

The OS preference technically reads "In windows and dialogs..." So perhaps we could just make the case that it doesn't say anything about "Web content areas" :)

Any "Web content area" is (almost always) in a window. And even if you did claim an exception for option menus in Web pages, it wouldn't be obvious why the same exception doesn't already apply to the option menus in iTunes Store pages. I think it would be more useful to argue that the benefit of making option menus focusable in Web pages by default outweighs the cost of contradicting what System Preferences says, than to pretend that System Preferences means something else.

Er, it sounds like this bug is a dupe of bug 349357 from all the discussion, but the summary currently includes "and other form controls", which is a quite different thing altogether (i.e., ignoring the FKA setting entirely and setting accessibility.tabfocus to 3 by default). If this is really just about adding <select>s to the key loop when FKA is off (to match Safari), someone should remove "and other form controls" from the summary. If not, bug 349357 should be un-duped and the p-safari that I just added to this bug's whiteboard should be removed.

cc'ing accessibility people since this also clearly impacts accessibility.

uiwanted: decide on the questions asked in comment #16

I am running Linux on my thinkpad - I should probably not work on this one as I won't be able to test my work easily.

This bug's priority relative to the set of other polish bugs is: P2 - Polish issue that is in a secondary interface, occasionally encountered, and is easily identifiable. I've had a lot of people contact me about this one, and it really is pretty annoying (enough that Safari is breaking the OS convention). The only reason it is a P2 is because we are limiting first to OS X users, and then to the subset of people who commonly use the keyboard to navigate forms.

Can we get this bug fixed? In the amount of time taken to find and mark bugs as duplicates of this bug, it could have been fixed. From a user perspective, this is a huge pain, I tab through everything and then have to manually go and set the select fields. Including every single form with a shipping address, where the states are always select fields. We don't need an option to honor the OS settings, there is no use case for skipping select fields in forms, or if there is it is so rare as to be ignorable. The bug's been passed around for almost two years now without being fixed. Please fix this. Thank you.

(In reply to comment #27) Time is not the only item required for this. You act like this is World of Warcraft and a developer merely must hit the "fix bug" button on this and after a few moments, it's resolved. There are other, more important bugs. This is a polish bug, not a bug that affects a large number of people negatively. However, there's something you can do that's more constructive than complaining! See the following link... http://www.amazon.com/gp/product/0470317264/?tag=mozilla-20

Maybe I'm missing something but this appears to already work in both 3.5.7 and 3.6 at: http://www.google.com/advanced_search I am able to tab to every control on the page, including the list boxes. You can pick an item in the list with up/down arrow keys, open the list to view vial opt+down arrow, or type the first few letters of an item to select it, just like any other app in OS X. You can also tab to combo boxes and submit buttons. Had FF already behaved like this, I never would've filed 408908 which, incidentally, is not really a duplicate of this bug at all. This has come down to a discussion about list boxes. 408908 was about buttons, primarily. Nothing like filling out a long form with only the keyboard to have to reach for your mouse to click "Submit" at the end because of some unchangeable option. Further, I second that there is not a use case for skipping these controls, despite OS X's settings. The inclusion of this option in the OS (and it's being turned on by default!) is rather baffling. Any person needing to skip a list box can simply press tab twice.

Neil: could you work on this bug as well since you are current dealing with focus issues on OS X? This is a pretty significant pain point for OS X users (decent number of, dupes, votes, public complaints, private emails, etc). Ideally this should apply to content but not chrome, for consistency with OS X's native tab focus behavior. >If this is really just about adding <select>s to the key loop when FKA is off >(to match Safari), someone should remove "and other form controls" from the >summary. I think full keyboard nav makes the most sense, especially since we are violating the standard platform behavior. I'm expecting that users will want to tab to check boxes and radio buttons as well, even though you also can't do that in OS X chrome UI.

This option is turned off in the settings because it means have to tab through everything in the chrome of an application. For example, in Mail, when the default is set the tab goes from the To: -> Cc: -> Subject: -> area to write your email With the other option it does: To: -> Cc: -> Subject: -> customize select -> from email select -> server select -> signature select -> and finally to the area to write your email I think that the intention of this option is what to do in the chrome of the browser, not in the web pages themselves. As to if you should tab through checkboxes and radio buttons too... I think it's not as important as that select box. Almost every consumer form has a select box for the "State" and "Country" dropdowns that have to be manually selected or have to deal with tabbing through lots of fields you obviously do not want selected. I say punt on the decision to include those fields or not and fix the selector issue. Thank you to anyone who attempts to get this in the queue to fix.

>This option is turned off in the settings because it means have to tab through >everything in the chrome of an application. Right, but since the filing of this bug (and the many dupes both before and after), we now have the capability of having different behaviors for content and chrome. >I say punt on the decision to include those fields or not >and fix the selector issue. We need to make a decision for the implementation. Aside from the user potentially having to hit tab a few more times when filling out a form if they hit a checkbox or radio button, does anyone have a really good reason why we shouldn't include these controls as well? While we generally try to give platform conventions precedence, any user who is accustomed to tabbing through all form elements on another platform ends up pretty frustrated on OS X when some of them are arbitrarily skipped (selects and check boxes, or just check boxes, etc.)

(In reply to comment #33) > While we generally try to give platform conventions precedence, any user who is > accustomed to tabbing through all form elements on another platform ends up > pretty frustrated on OS X when some of them are arbitrarily skipped (selects > and check boxes, or just check boxes, etc.) FWIW, Camino has always set accessibility.tabfocus to 3 (this only applies to content for us; chrome is still controlled by the OS), because it was a longer-standing Mac browser tradition (particularly on the Netscape side) to support tabbing to all form controls. I don't advocate abandoning OS conventions willy-nilly (and we made the change to 3 on our end with some argument--ironically about the same time Firefox implemented the new value for that pref that said "follow the Mac OS X FKA setting"), but we've received less than one handful of complaints over the years that we don't behave like Safari or the rest of the OS *in content*, so this has been a relatively safe, minor, and uncontroversial deviation, if that data helps the Firefox UX team make a decision. (In reply to comment #31) > >If this is really just about adding <select>s to the key loop when FKA is off > >(to match Safari), someone should remove "and other form controls" from the > >summary. > > I think full keyboard nav makes the most sense, especially since we are > violating the standard platform behavior. I'm expecting that users will want > to tab to check boxes and radio buttons as well, even though you also can't do > that in OS X chrome UI. I'll undupe bug 349357, then; it really is a separate issue and can be FIXED/WONTFIXed "independently" (though I think that if setting accessibility.tabfocus for content to 3 is what happens here, that bug is probably moot).

(I also think hyatt's explanation for why Safari does [the more limited] bug 349357 supports the argument for tabbing to all form controls, too; see bug 349357 comment 11.)

Just looked at the browsers at various settings on Mac: FF on Mac - skips select, checkbox, radio when os setting on text or list only Opera - does not skip select menu or radio, regardless of OS settings Safari - Does not skip select, regardless of OS settings Does skip radio inputs when os settings are on text or list only Chrome - Does not skip select menu or radio, regardless of settings

Sorry to be the newbie here — is this a pref we can just flip and get the bug closed for Firefox 4, or is are there any architectural issues? The UX team agrees that this pref should not be honored for web page content, similar to other browsers, and to reduce surprise for users that are trying to navigate web pages using the keyboard.

It's easy to change. The following adds tabbing for <select>. Are there others that are desired?

I'm personally fine with adding full keyboard nav for all form elements. I also think that this is the expected behavior, skipping certain types of fields seems arbitrary (even if we do now support <select>, which is commonly complained about). Unless anyone disagrees, I think we should pick up the other controls as well.