Closed Bug 417176 Opened 15 years ago Closed 14 years ago

better keyboard shortcuts for switching tabs on mac os x


(Firefox :: Keyboard Navigation, defect)

Not set



Firefox 3


(Reporter: stuff, Assigned: jacob)



(Keywords: user-doc-complete)


(2 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.12.2 (KHTML, like Gecko) Version/3.0.4 Safari/523.12.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3

Firefox does not support the standard keyboard shortcuts for switching tabs. Those are ⌘+{ and ⌘+} on US keyboards. They are used pretty much everywhere (Safari, Opera, RSS Readers, ...).

Firefox currently uses Ctrl+PgUp and Ctrl+PgDn, however this is quite awkward. Not only because it's uncommon but also because you have to press PgUp/PgDn, two keys vertically next to each other, when in fact you want to go left and right in the tab bar.

It would also be beneficial to have two entries for switching tabs in the menu, probably under "Window", like Safari does. Then one can create his own shortcuts using Mac OS X keyboard system preferences.

Reproducible: Always
Firefox also supports Ctrl+Tab and Ctrl+Shift+Tab and Cmd+(digit) for switching tabs, btw.
Ctrl+tab is not as easy as on PC's to hit with MacBook keyboard.  They only have Control key on the left side and the combination with Tab seems a little difficult compared to general keyboards used for PC.  
I also wish Firefox will allow Command+},{ for switching tabs.
Duplicate of this bug: 419922
cmd-alt-left/right also works
Duplicate of this bug: 419993
Ever confirmed: true
This patch was against beta3.  I have not yet done a full build using this
patch, but i updated the installed tabbox.xml from my Minefield.
Attachment #306263 - Flags: review?
Attachment #306263 - Flags: review? → review?(
Component: Keyboard Navigation → XUL Widgets
Product: Firefox → Toolkit
QA Contact: keyboard.navigation → xul.widgets
Comment on attachment 306263 [details] [diff] [review]
Add Cmd+{,} keybindings to tabbox

These keybindings should be set just for tabbrowser-tabs (that is, not for every tabbox).
Attachment #306263 - Flags: review?( → review-
i had originally attempted to apply the patch here, but had been thrown by the keyCode/charCode difference, and the other place looked easier once i had found it.

anyway, how's this one?
Attachment #306263 - Attachment is obsolete: true
Attachment #306431 - Flags: review?(mano)
For the curious and/or anxious (including myself), I've made a tiny extension that adds the changes in this patch:

Tested on 3.0b3 release and 3.05pre nightly.
Is there a reason to prefer hardcoding this in tabbrowser.xml, instead of adding a couple lines to mainCommandSet and mainKeyset in browser.xul?

I've tested an extension (attached) that does the latter, adding just

<command id="cmd_nextTab" 
<command id="cmd_prevTab" 


<key id="key_nextTab" key="}" modifiers="accel,shift" command="cmd_nextTab" />
<key id="key_prevTab" key="{" modifiers="accel,shift" command="cmd_prevTab" />

and it seems to work identically to the built-in shortcuts.

Doing it this way would be localizable, allows you to use "accel", and seems quite a bit more elegant.
From a UI perspective, this is the right thing to do and has my ui-r.

From an implementation perspective, I suspect that adding to the command set is preferable to hardcoding a binding, but maybe that's not as nice for other apps that pick up tabbrowser?
Oh, that's XBL bindings that I want to avoid. Nevermind and as you were!
Could test this with event synthesis, but I don't think our mochis currently let us dispatch trusted events against browser elements.

The tests would be:

- create N tabs
- select tab 1
- synthesize the next-tab keystroke, check we're on tab 2
- synthesize the prev-tab keystroke, check we're on tab 1
- synthesize prev-tab again and check that we're on tab N
- synthesize next-tab and check that we're on 1
(In reply to comment #13)
> Could test this with event synthesis, but I don't think our mochis currently
> let us dispatch trusted events against browser elements.
> <snip>

Hmm, I've had issues with browser shortcuts (specifically, ctrl+b) when writing mochitests for accesskeys... are those that different from the browser element case? (Just a thought...)

Comment on attachment 306431 [details] [diff] [review]
add new bindings to tabbrowser.xml

Attachment #306431 - Flags: review?(mano) → review+
Component: XUL Widgets → Keyboard Navigation
Product: Toolkit → Firefox
QA Contact: xul.widgets → keyboard.navigation
Assignee: nobody → jacob
Target Milestone: --- → Firefox 3
Version: unspecified → Trunk
Comment on attachment 306431 [details] [diff] [review]
add new bindings to tabbrowser.xml

a=beltzner, please make sure the test plan from comment 13 is actioned!

Yay for UI improvements from new contributors!
Attachment #306431 - Flags: approval1.9? → approval1.9+
adding in-litmus? for the test in comment 13, in case we don't get a chrome test written
Flags: in-litmus?
Checking in browser/base/content/tabbrowser.xml;
/cvsroot/mozilla/browser/base/content/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.270; previous revision: 1.269
Closed: 14 years ago
Flags: in-testsuite?
Keywords: checkin-needed
Resolution: --- → FIXED
Keywords: user-doc-needed
How is this implemented for non-US keyboard layouts? In other applications (Safari, Terminal), the shortcut is changed to remain on the same physical keys. However, this is done on a per-language-bundle basis which means if you are a non-US user using a US keyboard layout, you are out of luck. It would be great if Firefox could implement a way of changing the shortcuts based on the user’s current keyboard layout.
(In reply to comment #19)
> It would be great if Firefox could implement a way of changing the shortcuts
> based on the user’s current keyboard layout.

The patch that landed uses the charCode, so Cmd plus whatever key combination is needed to produce "{" or "}" with your keyboard layout should work. It would be great if you could test and report back, though, using a build from .
I tested it quickly with German and Swiss German keyboard layouts: It does not work. The keys needed to enter the curly braces are opt+8 and opt+9. Pressing cmd+opt+8 or cmd+opt+9 does nothing in the latest trunk nightlies (I confirmed that it works with the US-English keyboard layout). The problem here really seems to be that, since another modifier key is involved, the shortcut is really treated as being cmd+opt+8 instead of resolving to cmd+{.
I was wrong, however, when I pointed out that the shortcuts would remain on the same physical keys. They’re on Ö and Ä (which would be the ; and ' keys in the US keyboard layout).
There are currenly two bugs in Apple’s implementation which I don’t want to see repeated by Firefox:
1. As I pointed out earlier: the shortcuts are not tied to the keyboard layout but to the user’s current language. Which means that a non-US user who (like me) who (like me) prefers to have his applications’ languages set to english (who’ll most likely have a non-US keyboard layout since you can only choose to have a different physical keyboard with your Mac if you buy it at the Apple online store) will have the shortcut on { and } keys even if they’re designed to be on other keys for that particular keyboard layout.
2. Safari has opposite directions for the tab switching (at least in the German resource bundles) than the Terminal. The directions are the same in the US keyboard layout. This, I think, just comes from sloppy internationalization and won’t likely happen to Firefox.
I should also point out that I am (although I live in Switzerland) am not affected by this particular issue since I have a US keyboard with the US keyboard layout and have set English as my preferred language, it’s just that I have a lot of friends who have complained to me about bad keyboard shortcut implementation. It would be great if Firefox could set an example in this matter. As it is implemented now, this is very US-centric and the implementation is worse than Apple’s. But it could be easily made better than Apple’s. Here’s how:
1. Add the ability to tie keyboard shortcuts to the currently set keyboard layout.
2. Add the default keyboard shortcuts cmd+{, cmd+}
3. Override them for specific keyboard layouts (cmd+ö, cmd+ä for German and Swiss German, others to match the way it’s done in Apple’s apps)
I realise that adding new functionality like this is not a simple task and won’t make it into the next release, however, I think that it would be prudent to seriously consider it for a later version of Firefox.
As of the latest nightly:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008041504 Minefield/3.0pre

something changed, and this is no longer working.  Instead of tabs being switched, i get my "alert" sound (from sysprefs -> sound -> sound effects).

I checked browser.jar, and the code is still there; I don't see any errors anywhere (Console, Error Console, terminal).  Anyone know what may have changed to break this?
filed Bug 429217 – [Mac]Regression: Cmd+{ and Cmd+} will not switch tabs has been added to Litmus and will be enabled when this functionality is working again.
Flags: in-litmus? → in-litmus+
You need to log in before you can comment on or make changes to this bug.