Development:Planning:Focus Chain

Draft of a Focus Chain to fix Bug 152987, Bug 198153, Bug 336949 and Bug 280963

All of these assume a start-point of the location bar, though in most real-world cases we focus the content area (or some part of the Manager) after loading the page/Manager. The chain should pick up from whatever element is focused in those cases, so that auto-focused chains and chains where the user puts focus somewhere behave the same, no matter the starting point.

Web pages

With FKA disabled

• Location bar (start)
• Search field (if not collapsed)
• Content area (actual initial focus)
  • then follow Gecko pref for tabbing/focus within the content area, but don't loop inside the content area
• Location bar (end)

Shift-tab merely reverses the direction of travel.

Issues with content-area tabbing

• Getting from the toolbar to the content area

  smfr mentioned this as a problem; at one point sbwoodside worked around it, which worked but caused Bug 198153

  • That no longer works at all; perhaps sbwoodside's hack broke at some point due to autocomplete/child window cleanup? [bet. 2004-06-01 and 2005-01-21]

• don't loop in Gecko, which is part of the problem in the current bug

  right now, we don't have a way to tell Gecko where the end is so that we can get back out, if a page has form controls (or you Gecko-pref links); this only works when a page has no focusable elements

  • Conrad says we need to do this

• ideally, even when a page has focusable elements, we should initially set focus to the entire page, not the first form element, so that arrow key scroll, etc., work

  doing that might help with the above

• Camino hard-codes the pref value for focus in the content area (Bug 316339, Bug 277706) to "do the right thing" based on user expectation; we currently need to expose UI in the prefs to allow the user to select the variety of tabbing option desired (Bug 277706).

With FKA enabled

• Location bar (start)
• Search field (if not collapsed)
• Toolbar buttons to the right of the search field (if any)
• Bookmark Bar first item (if Bookmark Bar is visible)
  • Proceeds through the remainder of the Bookmark Bar items; upon reaching the bottom-rightmost item:
• Tab bar first tab (if Bookmark Bar is visible)
  • Tab proceeds through the active tabs and down-arrow moves the focus into the content area

  'or, since the OS tab behavior is different

  • Arrows go left/right along the tab bar (activating each tab as you reach it) and tab takes you into the content area

    I think we should do this; it's "cleaner" and how the OS works (and Firefox, but not Safari)

• Content area (actual initial focus)
  • follow Gecko pref for tabbing/focus within the content area, but don't loop inside the content area
• Leftmost toolbar button
• Location bar (end)

Shift-tab merely reverses the direction of travel.

Issues with tab bar transversal

• Where does the tab close button fit in the chain? (with either method of transversal)
  • They're controls, but they're really not needed with Cmd-W
  • Safari includes them, but BonEcho does not
  • Window close globes are controls, too, but they're not FKA-focusable, either

  Decision: it doesn't belong in the chain at all

• If arrows cycle between tabs (like in the OS), we have OS consistency but the tab bar and the other toolbars behave differently from each other
  • this is logical because 2 are toolbars and one is tabs, but will users realise that?
  • AHIG:
    • "Pressing the Tab key navigates between controls. Shift-Tab navigates in the reverse direction. The arrow keys provide navigation within controls. In list views, the Right Arrow and Left Arrow keys open and close disclosure triangles."
• If tab moves between tabs and down-arrow brings focus into the content area, shift-tab will still get you back from the content area to the tab bar, but breaks the parallelism
  • I.e., normally tab goes one direction and shift-tab reverses; here down-arrow goes the one direction but shift-tab reverses

Issues with content-area tabbing

• See list above

Manager views

With FKA disabled

• Location bar (start)
• Search field (if not collapsed)
• into the Manager
  • Manager search field (actual initial focus)
  • Manager right (outliner) pane
  • Manager left (Collectons) pane
• Location bar (end)

Shift-tab merely reverses the direction of travel.

With FKA enabled

• Location bar (start)
• Search field (if not collapsed)
• Toolbar buttons to the right of the search field (if any)
• Bookmark Bar first item (if Bookmark Bar is visible)
  • Proceeds through the remainder of the Bookmark Bar items; upon reaching the bottom-rightmost item:
• Tab bar first tab (if Bookmark Bar is visible)
  • See corresponding section in Web pages for order
• into the Manager
  • Manager search field (actual initial focus)
  • Manager right (outliner) pane
  • Manager left (Collectons) pane
  • New Collection menubutton
  • New separator/folder/etc. menubutton
  • Action menubutton
  • Sort menubutton
• Leftmost toolbar button
• Location bar (end)

Shift-tab merely reverses the direction of travel.

Issues

• How do you access the menu in the search field (to select the filter type)?
• How do you access the column headings to change sort order or which field to sort upon?
  • Or to resize them

  Some things just aren't (can't be) accessible here, just like you can't customize a Cocoa toolbar with a keyboard....

Assorted thoughts

i.e., why we're doing Manager focus this way

• AHIG:
  • "In Roman systems, focus always begins at the first field that accepts keyboard input and follows a reading path from upper left to bottom right."
  • "Pressing the Tab key navigates between controls. Shift-Tab navigates in the reverse direction. The arrow keys provide navigation within controls. In list views, the Right Arrow and Left Arrow keys open and close disclosure triangles."
• let's make it as useful as possible, while trying (but not religiously) to follow the HIG
  • hwaara: are we talking initial focus or just tab order?
  • ardissone: both, i think; "focus always begins"...
  • ardissone: putting initial focus in the search field makes sense from a practical standpoint
  • ardissone: it's hard to argue against that
  • ardissone: the problem is, given where we locate that field, it make the subsequent order seem awkward
  • ardissone: (at least in terms of getting back up to the toolbar)

  ...

  • hwaara: for me the order is not that important, as long as search gets initial focus
  • ardissone: if we do a search, then the user is going to want to use those results
  • ardissone: so your current order makes sense
  • ardissone: search -> outliner -> collections
  • ardissone: maybe that's the determining factor, if we accept default focus is the mgr search field

• Except in this case we ended up doing what Apple recommends, upper right to bottom left, so focus moves from the search field (initial) to the Collections to the outliner (with FKA off); see Bug 337144.