User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8) Gecko/2007091211 GranParadiso/3.0a8 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8) Gecko/2007091211 GranParadiso/3.0a8 The Up/Down keys switch tabsin the Extentions/Theme Manager. A second attempt to view the manager fixes the bug. Reproducible: Sometimes Steps to Reproduce: 1. Open the Extensions/Themes Manager. 2. Press Left or Right. 3. Watch the selected tab change. Actual Results: The selected tab changes. Expected Results: The selection in the content list should move up or down. This only happened the very first time I viewed the manager after installing GranParadiso.

Did a extension or theme have focus in the list at the bottom? if not then that is by design.

I have experienced a similar problem. When initially opening the Extensions/Themes Manager, using the Up and Down keys will correctly scroll up and down the addons list. However, Left and Right do not switch the tab. If another tab is selected with the mouse, Left, Right, Up and Down all switch through the tabs only - Up and Down do not scroll through the list. By selecting an item in the list, Up and Down functionallity works again, however Left and Right will no longer switch the tabs. When switching into a new tab in the Extensions/Themes manager, an item appears to have focus, however the actual focus does not seem to exist until you click upon that item or another item in the list.

This follows the suggestion in bug 446399 comment 2. I'd like to try to get this into 1.9.1 if there's another RC. Keyboard navigation in the add-ons manager is quite depressing right now...

Marco, could you please try this patch and see if it confuses screen readers?

(In reply to comment #4) > Marco, could you please try this patch and see if it confuses screen readers? I just tried the patch, and have two comments: 1. I'm fine with Left and Right Arrow switching tabs and repopulating the lists when focused on the list of extensions, themes, search results etc. 2. What I do not like is the fact that when focused on the tabs, right arrowing will shift focus to the items list automatically. I am generally against automatic focus switching, and this case prevents the screen readr user from actually hearing what the tab they just moved to actually is. To find that out, they'd have to shift tab back to the tabs list to hear the currently selected tab again. And I believe in general pulling focus away from one control to another when the user just expects to switch tabs is not good practice. So if you can change the patch so that when focused on the tabs, left and right will switch to the new tab, but keep focus there, I'd be fine with it. Note that the other switching of tabs is OK, since the focus *remains* in the items list.

removed the focus change

(In reply to comment #6) > removed the focus change This works great!

Comment on attachment 379428 [details] [diff] [review] patch v2 This is good and does pretty much what I need. I have little concern that we're listening to the keyboard so globally, if any add-ons add content to the UI then we'll steal focus from them. You at least need to filter out keyboard events when a button is focused I think. Perhaps it would be better to just attach the event listener to the view group and the richlistbox? Can you also add handling for page up/down and home/end?

That seems slightly too limiting for my taste (I don't consider arrow keys on buttons all that useful), but I guess effectively it fixes the most common use cases that have been reported here.

forgot about pageUp, pageDown, home and end

Verified fixed with builds on Windows and OS X like: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090731 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090731044744 Will an automated test be possible?

This was against the previous UI so is no longer relevant