The "All Tabs" menu should show the numerical shortcuts for each of the first eight tabs and the last tab. This would make it easier for users to discover these nifty shortcuts. I'll let you guys fight over whether the last tab should show ⌘5 or ⌘9 when there are only five tabs (since ⌘9 is special and always goes to the last tab). UI precedent: Safari uses ⌘1 through ⌘9 for bookmarks toolbar items and shows the shortcuts in the "bookmarks bar" submenu of the bookmarks menu.

Comment on attachment 538306 [details] [diff] [review] Set the key attribute as needed after each menuitem is built. This doesn't update the key attributes when tabs are closed / opened. I think we can just remove the TabOpen handler (it's not clear how a tab would be added while the popup is open, and TabMove isn't handled either), but for TabClose we should update the key attributes.

An alternative for _updateKeyAttributes is to set the attribute on all the relevant items without looking at the value of the removed item's key attribute. The main difference is that code is a little cleaner to read than this patch (no parameter and don't attempt to extract the key number from the removed item's attribute).

Comment on attachment 538618 [details] [diff] [review] Update item key attributes on item removal. _updateKeyAttributes could just remove all present key attributes and set them anew. This way, it could be called from the popupshowing handler as well as the TabClose handler.

Thanks for the feedback, Dão. This version of the patch overwrites the key attributes over the set of items that need key attributes, allowing the method to be used from both handlers. It does not remove the attributes first; they will be overwritten if they exist at all. In the case of popupshowing, they do not exist yet. For TabClose there cannot be an item that has a key before the removal that will not get one written.

Comment on attachment 538982 [details] [diff] [review] Use _updateKeyAttributes from both the TabClose handler and popupshowing handler. Looks good!

Comment on attachment 538982 [details] [diff] [review] Use _updateKeyAttributes from both the TabClose handler and popupshowing handler. what if we only displayed the keyboard shortcuts for app tabs? This way they would remain consistent (well as consistent and the user's app tabs remain consistent), as opposed to the normal tab strip which is always changing. Any command+# shortcuts higher than the number of app tabs would of course still work, but unlike app tabs the user might not remember what is open at the start of their tab strip, so they would be less useful.

Well, if you have X app tabs, it still seems useful to know that Ctrl+(X+1) can get you to the first transient tab, whatever that tab contains, just like Ctrl+9 always gets you to the last tab. This is basically a hidden feature right now, and exposing it only for app tabs would keep it half-hidden.

FWIW, my tab strip overflows all the time and I use these shortcuts a lot to scroll to the first or last tab.

>This is basically a hidden feature right now, and exposing it only for app tabs >would keep it half-hidden. yeah, basically. I would like to expose the part that provides consistent shortcuts for persistent content. That half seems more memorable and useful.

Right, but Ctrl+9 consistently means "last tab" and Ctrl+(X+1) is similarly somewhat consistent for "first transient tab" if you don't add and remove app tabs all the time (which you're basically assuming already). I know of no other way to move across an overflowing tab bar as efficiently.

Well Home is going to end up at control+1 when introduced as the user's first app tab. So that will provide the tabs trip traversal trick. I'm just reluctant to expose shortcuts for (commonly) changing content.

Are you saying that selecting the home tab would scroll the tab strip to the start? I don't think I understand...

I just meant in terms of tab focus (first tab after the apps tabs gets focus with control-tab)