Open
Bug 404416
Opened 18 years ago
Updated 3 years ago
Show keyboard shortcuts (⌘1 through ⌘9) in the "All Tabs" menu
Categories
(Firefox :: Tabbed Browser, enhancement)
Tracking
()
NEW
People
(Reporter: jruderman, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 2 obsolete files)
4.08 KB,
patch
|
dao
:
review+
faaborg
:
ui-review-
|
Details | Diff | Splinter Review |
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.
Updated•15 years ago
|
OS: Mac OS X → All
Comment 2•14 years ago
|
||
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).
Attachment #538306 -
Attachment is obsolete: true
Comment 4•14 years ago
|
||
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.
Attachment #538618 -
Attachment is obsolete: true
Comment 6•14 years ago
|
||
Comment on attachment 538982 [details] [diff] [review]
Use _updateKeyAttributes from both the TabClose handler and popupshowing handler.
Looks good!
Attachment #538982 -
Flags: ui-review?(faaborg)
Attachment #538982 -
Flags: review+
Updated•14 years ago
|
Assignee: nobody → unusualtears
Comment 7•14 years ago
|
||
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.
Attachment #538982 -
Flags: ui-review?(faaborg) → ui-review-
Comment 8•14 years ago
|
||
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.
Comment 9•14 years ago
|
||
FWIW, my tab strip overflows all the time and I use these shortcuts a lot to scroll to the first or last tab.
Comment 10•14 years ago
|
||
>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.
Comment 11•14 years ago
|
||
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.
Comment 12•14 years ago
|
||
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.
Comment 13•14 years ago
|
||
Are you saying that selecting the home tab would scroll the tab strip to the start? I don't think I understand...
Comment 14•14 years ago
|
||
I just meant in terms of tab focus (first tab after the apps tabs gets focus with control-tab)
Comment 15•3 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee: unusualtears → nobody
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•