1132036 - Make all items in the Navigation toolbar keyboard focusable

Status: RESOLVED DUPLICATE of bug 1418973

(Firefox :: Toolbars and Customization, defect)

Description

[Marco Zehe (:MarcoZ)]

Now that F6 switches panes reliably, it is finally time to make all items in the Navigation toolbar tabable. There are so many items that no longer get menu equivalents, add-ons plug their stuff in there, social API providers, too, that it is no longer feasible to try and invent keyboard shortcuts for everything.

Proposal:
1. Keep Ctrl+L and Ctrl+K as they are.
2. Make Tab focus *every* control in the Navigation toolbar. So even between the address and search fields, and everything after the one-off buttons should be reachable via the tab key.
3. Don't discriminate between our own buttons and those plugged in via add-ons, just cycle through everything.
4. After the end of the tool bar, move to the next item as usual.

Comment 1

[:Gijs (he/him)]

This breaks platform conventions pretty much everywhere and probably will have quite a lot of hiccups on the actual individual items (AKA can of worms). And that's not even talking about the massive amount of work it'd be to make the main menubutton properly keyboard-accessible (see previous bugs on that subject).

To me, fixing whatever items (social, hello) don't have keyboard alternatives is much more attractive. Why is that "no longer feasible" ?

Comment 2

[Marco Zehe (:MarcoZ)]

1. There are only 26 letters in the alphabet. Plus maybe some more keys we might be able to combine with ctrl and shift keys.
2. This will introduce potential key comflicts with add-ons. We alreadyhave some of these IIRC where browser and add-ons shortcuts combat for priority. And I haven't even started thinking about how we want to make those known to the user.
3. Platform conventions are already broken in a lot of places by Microsoft and others. Look at Office or Windows Explorer ribbons, and other toolbars that can be navigated because apps or programs no longer have a normal menu system any more.
4. This would only fix our stuff, but as soon as an add-on plugs itself into that toolbar, it is again not reachable.
5. Only other option I see is adding another top level item to the conventional menu bar that holds all of the otherwise not reachable toolbar buttons as menu items, which would require us to create a mechanism that adds a menu item to that menu as soon as an add-on author adds a toolbar button.

Comment 3

[:Gijs (he/him)]

(In reply to Marco Zehe (:MarcoZ) from comment #2)
> 1. There are only 26 letters in the alphabet. Plus maybe some more keys we
> might be able to combine with ctrl and shift keys.

I don't think it's required to have shortcut keys for all of these things, so I don't think this is a good argument. Having regular old menu items for what is possible with the toolbarbuttons seems like a very doable thing for both hello and social, and we should just make that happen.

> 2. This will introduce potential key comflicts with add-ons. We alreadyhave
> some of these IIRC where browser and add-ons shortcuts combat for priority.
> And I haven't even started thinking about how we want to make those known to
> the user.

Ditto.

> 3. Platform conventions are already broken in a lot of places by Microsoft
> and others. Look at Office or Windows Explorer ribbons, and other toolbars
> that can be navigated because apps or programs no longer have a normal menu
> system any more.

I'm sympathetic to the practical side that "apps without menus do this, so there kind of is a convention", although I'll note that the general theory here ("bad practice X is OK because Y did it first") isn't great.

Worse, there also still really isn't a good precedent to do this on OS X and Linux, and we should fix the problem for those users, too.

> 4. This would only fix our stuff, but as soon as an add-on plugs itself into
> that toolbar, it is again not reachable.

And that's a bug with the add-on. Just like if we make the toolbarbuttons tabbable, that's not going to fix toolbarbuttons that use mousedown handlers, or <toolbaritem>s that contain non-button items.

We can't fix add-ons for their authors in a general way. We just can't. They can do too much random stuff for us to do that.

Comment 4

[:Gijs (he/him)]

IOW: counter-proposal: social and hello should get menuitems that provide keyboard equivalents for everything their buttons do.

Comment 5

[:Gijs (he/him)]

Marco, how do you feel about comment #3?

Comment 6

[Marco Zehe (:MarcoZ)]

I'm fine with going with comment 4.

Comment 7

[David Bolter [:davidb] (NeedInfo me for attention)]

NI Gijs so he sees comment 6.

Comment 8

[:Gijs (he/him)]

Seems like we need to ensure we have bugs on file for both. Shane and Mike, can you either file or point to bugs to provide keyboard-accessible alternatives for the social share and loop infra, respectively?

Comment 9

[Mike de Boer [:mikedeboer]]

I filed bug 1147794 for Hello.

Comment 10

[Shane Caraveo (:mixedpuppy)]

I'd assume that bug 1114911 covers this.

Comment 11

[James Teh [:Jamie]]

Closing as a duplicate of bug 1418973, since this has been revived there in the new era.