STR: 1. Open a message in the full reader window or the Preview pane. 2. Press Shift+Tab until focus lands on the "More Options" button. 3. As with any other button, hit Space. Result: Nothing happens. Expected: The options should become available. 5. Click on the button using the mouse. Result: The list of options now becomes active, but does not get the keyboard focus. Suggested solution: Turn the More Options button into a regular menu button that pops up a menu of options, much like the popup would come up for color picking etc. That way, both problems would be solved: The activation via Space and the fact that keyboard focus does not go to the available options.

Do you mean "Other Actions"? This WFM with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20081211 Shredder/3.0b2pre.

Hi Tyler, thanks for checking! It does indeed open the list, but does not put keyboard focus there. Keyboard focus remains on the button, and one has to press DownArrow to get to the list of actions. I adjusted the summary, and I still think this should be morre like a menu button type of thing.

OK, now I understand and see that behavior.

Marco, should spacebar also operate "hide details" and expand the header? I find that it scrolls the message instead.

(In reply to comment #4) > Marco, should spacebar also operate "hide details" and expand the header? I > find that it scrolls the message instead. Yes, it should do these actions, since these are buttons as well.

I'm a little puzzled about what we're doing wrong, since it _is_ a menu button thing: it's just a <button type="menu"> without much fanciness going on, other than an onPopupShowing handler that disables and hides some items. And having to hit the down arrow to get to the first item in a button or toolbarbutton type="menu" seems to be how it works. For the Firefox feed button in the addressbar, when a page has more than one feed, and the chevron button in the bookmarks toolbar when you have enough bookmarks to overflow, and the Insert and Smilie menubuttons in Thunderbird's HTML compose formatting bar, click opens, then you have to hit the down arrow to get to the first item. I do find it sort of odd that I couldn't find another button type="menu" which you can tab to in order to focus, though: the closest I found was the "menu" in the Firefox Bookmarks Organizer on OS X, which explicitly puts the focus in the bookmarks tree onPopupShowing. Now, bug 521928, *that* I would expect to mess you up, badly, but I don't see why this isn't just the expected behavior, since it seems to be how the widget works.

Imo, having to hit the down arrow isn't the issue here. This is standard practice for context menus, at least in Windows. The problem is that the focus doesn't change at all, so when I hit the button, I have no idea that a menu has popped up. Normally, when a menu button is activated, focus should land on the menu, after which down arrow will land focus on the first menu item. Also, this menu is actually presented to a11y as a "list" for some reason instead of a "menu".

And how does that compare to the behavior of a <button type="menu"> in Firefox 3.5?

Is this still valid in current TB? How can we see the focus is not where it should be?

Wfm in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Thunderbird/15.0a1

Err, build ID is 20120528030202. I'm used to this showing up in the user agent string, but it doesn't seem to any more.