256635 - [Linux] N-th tab shortcuts should use Alt-1 to Alt-9 rather than Ctrl-1 to Ctrl-9

Status: RESOLVED FIXED

(Firefox :: Keyboard Navigation, defect)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The tab-switching keyboard shortcuts on Linux currently use Ctrl-1 (switch to
first tab) through Ctrl-9 (switch to 9th tab).  This is inconsistent with other
apps, such as gnome-terminal and xchat, which use Alt-1 through Alt-9 for this
same functionality.  We should switch to using Alt for these shortcuts on
GTK/GTK2 builds at least.

(Note that our Ctrl-PgUp and Ctrl-PgDn shortcuts for next/previous tab *are*
consistent with gnome-terminal and xchat, so those should stay Ctrl.)

Comment 1

[Aaron Leventhal]

I'm not going to get to this.

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch

This should do it.

Comment 3

[Phil Ringnalda (:philor)]

*** Bug 262628 has been marked as a duplicate of this bug. ***

Comment 4

[L.C. (Laurentiu C. Badea)]

Since the top mentioned the Ctrl-# shortcuts, I should mention that the 
Ctrl-# shortcuts do not seem to work either.

Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041002 Firefox/0.10.1
(RPM from Fedora dev tree)

Comment 5

[Asa Dotzler [:asa]]

Comment on attachment 160711 [details] [diff] [review]
Patch

a=asa for aviary checkin.

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

Fixed.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It looks like this (or, rather, a modified version of the attached patch) was
landed on the Aviary branch (corresponding to the fixed-aviary1.0 keyword) but
not on the trunk (corresponding to the FIXED resolution).

Comment 8

[Christopher Aillon (sabbatical, not receiving bugmail)]

Righto.  Checked in on trunk now.  Thanks.

Comment 9

[Jeff Walden [:Waldo]]

What's the reason for *removing* support for the Ctrl+[N] set of shortcuts on
Linux?  Supporting Alt+[N] makes perfect sense, but it doesn't make sense to
also remove Ctrl+[N] for those who've grown accustomed to using Ctrl+[N].  If
there's no real conflict with Ctrl+[N], then I don't see why both can't be
supported on Linux.

Can anyone tell me why Ctrl+[N] can't be enabled in addition to Alt+[N] for
Linux?  If it's safe to reenable it, I'll make the patch.

Comment 10

[Christopher Aillon (sabbatical, not receiving bugmail)]

It's silly to have duplicate keybindings, especially for new users.  If they
inadvertently learn the Ctrl bindings, it may confuse them when they use other
applications.  Also, who is to say that the Ctrl bindings won't be sucked up for
some other purpose in the future?  Its safest to be consistent across the board.

Comment 11

[eric lindvall]

Is this going to conflict with my Window Manager's ALT+1-9 to specify which
virtual desktop to use?

Comment 12

[Per Ångström]

Using ALT+digit for selecting tabs conflicts with web pages that use the
accesskey attribute together with numerical access keys. Please consider
reverting this fix.

See http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey for more
information about access keys.

See http://diveintomark.org/about/accessibility/ for a site that uses access
keys in a way that does no longer work reliably in Firefox.

Comment 13

[W. Tellier]

Is it possible to change this back to ctrl + # ?
Alt+# is used to change desktops in windowmaker, although it can be changed I've
been using those keys years before firefox showed up, so changing those is not
really an option for me.

Comment 14

[Stephen Thorne]

Hmm.

At the very least, we could have an about:config option should exist to allow us
to use control-# instead of alt-#...

Also, this page bears updating, if you wish to continue to have a non-standard
key combination for gtk users: http://www.mozilla.org/support/firefox/keyboard

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

For the people who say this now conflicts with their window manager: I (the
patch author) sympathize.  I have used WindowMaker for over 6 years now, which
captures Alt+[1-9] to switch workspaces.  I have recently started using
Metacity, and have since set the keyboard preferences to switch workspaces with
Alt+[1-9].  However, the number of users that this conflicts with because of
window managers is relatively small in the grand scheme of things.  When other
popular applications do the same thing, it is best to be consistent.

I also sympathize in part with the accesskey issue.  I feel though that there is
a much greater problem that needs to be solved.  Access keys on web sites can
sometimes interfere with general menu usability.  For example, on this very
bugzilla, I can't press Alt+F to open the File menu.  I do wish that there were
a better mechanism to negotatiate what happens when the application and website
conflict in key usage....  I think that for right now, this isn't a huge issue
for websites (most sites I'm aware of either don't use accesskeys or use alpha
keys).  I feel though that the application shortcuts should always override the
site defined shortcuts.

I'd say a separate bug is warranted to figure out what to do here.

Comment 16

[Per Ångström]

I am the reporter of bug #264204, "[Linux] ALT-digit tab-selection shortcuts
conflict with accesskey assignments".

I would like to point out that numeric access keys have been used by quite a few
site authors precisely because they had less risk of colliding with built-in
accelerator keys.