417176 - better keyboard shortcuts for switching tabs on mac os x

Status: RESOLVED FIXED

(Firefox :: Keyboard Navigation, defect)

Description

[Max Amanshauser]

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

Comment 1

[Jesse Ruderman]

Firefox also supports Ctrl+Tab and Ctrl+Shift+Tab and Cmd+(digit) for switching tabs, btw.

Comment 2

[Louise]

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.

Comment 4

[Jo Hermans]

cmd-alt-left/right also works

Comment 6

[jacob berkman]

Attachment: Add Cmd+{,} keybindings to tabbox

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.

Comment 7

[Asaf Romano (gone)]

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).

Comment 8

[jacob berkman]

Attachment: add new bindings to tabbrowser.xml

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?

Comment 9

[jacob berkman]

For the curious and/or anxious (including myself), I've made a tiny extension that adds the changes in this patch:

http://off.net/~jacob/mactabswitch-1.0.xpi

Tested on 3.0b3 release and 3.05pre nightly.

Comment 10

[Wes Campaigne]

Attachment: Extension that adds cmd+{,} shortcut using XUL key and command elements

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" 
  oncommand="gBrowser.mTabContainer.advanceSelectedTab(1,true);"/>
<command id="cmd_prevTab" 
  oncommand="gBrowser.mTabContainer.advanceSelectedTab(-1,true);"/>

and

<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.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

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?

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Oh, that's XBL bindings that I want to avoid. Nevermind and as you were!

Comment 13

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

Comment 14

[:Gijs (he/him)]

(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 15

[Asaf Romano (gone)]

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

r=mano.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

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!

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

adding in-litmus? for the test in comment 13, in case we don't get a chrome test written

Comment 18

[Reed Loden [:reed]]

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
done

Comment 19

[Raphael Schweikert]

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.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

(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 ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ .

Comment 21

[Raphael Schweikert]

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.

Comment 22

[jacob berkman]

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?

Comment 23

[Louise]

filed Bug 429217 – [Mac]Regression: Cmd+{ and Cmd+} will not switch tabs

Comment 24

[Marcia Knous [:marcia]]

https://litmus.mozilla.org/show_test.cgi?id=5278 has been added to Litmus and will be enabled when this functionality is working again.