Shortcut keys in Linux Mozilla not in line with standards for KDE/Gnome




20 years ago
11 days ago


(Reporter: djoham, Assigned: akkzilla)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3+][p:4])


(1 attachment)



20 years ago
KDE and Gnome both define accelerator keys with the control key rather than the
alt key. However, Mozilla build 1999122208 uses the ALT key as its accelerator.

I understand that Navigator 4.x uses ALT, but for consistency with the two most
popular desktop environments, I believe continuing the old-style key combination
would be a mistake.

I believe the accelerator keys should be:
CTRL-N 	- New Navigator Window
CTRL-C 	- Cut
CTRL-V 	- Paste




20 years ago
Assignee: nobody → shuang
Component: Browser-General → UE/UI
Reassigning to German Bauer for approval; I warned him that this might be a
problem, exactly a month ago. :-) German can then reassign to the appropriate
XPApps person.
Assignee: shuang → german
Component: UE/UI → XPApps
QA Contact: nobody → sairuh
spam: reassigning QA contact to self, assigned to german, updated to XPApps and
cc'd mcafee since he has bug 22529 and might have additional wisdom about this
bug... :-)

Comment 3

20 years ago
Let me launch a quick poll (as promised a month ago :-) with n.p.m.unix and
n.p.m.ui. The reason I am hesitating is that 4.x did this due to Emacs


20 years ago
Assignee: german → don

Comment 4

20 years ago
Based on a discussion on the newsgroups
(to view thread click this link: news://news/
Based on the discussion there it seems worth considering putting in the effort
for some sort of switching/ config UI for Unix/Linux users. Also, based on
this discussion and the email I have received earlier (even from 4.x
timeframe) it is safe to go with Ctrl  for most Unixes/Linuxes as the default
qualifier key for all app accelerators, which can then be changed. I'll send this
back to the apps team.

Comment 5

19 years ago
Target Milestone: M16

Comment 6

19 years ago
Emacs has too many strange keybindings and is too different from standard GUI
apps (even unix Motif apps).

Please use the Motif/CDE/KDE/GNOME/Windows/OS2/Mac standard which
is Ctrl+key for menu accelerators and Alt+key for activating the menus.

When this is done, then start thinking about configurability...

Keywords: pp
Hardware: PC → Other


19 years ago
Depends on: 23587

Comment 7

19 years ago
I'm going to throw my .02 in here for what its worth. I've seen some comments of
frustration by the Mozilla developers about what should be done about this
problem. Seems that there is some dissention about what the standard should be
and what Mozilla will use.

I would like to point out a historical reference about Mozilla that would
justify the use of the CTRL key for key bindings and the ALT key for menu
operations. A long time ago, it was decided that Mozill first and foremost was
going to be a standards compliant browser. This meant that support for non-W3C
tags (i.e. LAYER) was tossed out the door as relics of the past in favor of
standards. I would like to suggest that Mozilla do the same in regards to the
key bindings. Even though Netscape used ALT-<key> in the past for things like
cutting and pasting, todays most popular window managers choose a different
standard. The following standards pages suggest that the CTRL key is now the
appropriate key for such things like cut and paste while the ALT key is used for
menu activation.



I would argue that if standards are important to Mozilla, the appropriate key
settings should be used regardless of what has been done in the past.



19 years ago
Target Milestone: M16 → M18

Comment 8

19 years ago
I don't know why this is being put off.

Just using the same keys as Windows would be a step closer to resolving this
problem. I haven't looked at things, but it seems to me that it shouldn't be
hard to use the windows bindings...

But Alt+Left,Right have to be the same as in 4.x (even on windows)!

Comment 9

19 years ago
As a start, changes need to be made in:


Changes are obvious (marked by #ifdef).

The chrome files definition of xulkey has to be changed. I am not sure how much
effect this has.

Additional problem to solve (I haven't looked it at yet) is getting Alt+Letter
working for accessing the menus.
Keywords: dogfood

Comment 10

19 years ago
Putting on [NEED INFO] radar.  How critical is this to Linux users for PR2?
Whiteboard: [NEED INFO]
akkana, pavlov --your thoughts?

Comment 12

19 years ago
My .02

I'm quite happy just that it's on your radar. I don't need it for PR2, just for the final release.

i agree with, it's cruical for the final release, at least for people new to linux (it's a bitch having to learn multiple shortcut paradigms). But being an experienced NS4.x user i've gotten used to the Alt-key shortcuts, so i can live with it for a while longer

Comment 14

19 years ago
As soon as 23587 is fixed, switching back and forth becomes easy.  I don't
really care which modifier becomes the default at that point (using control
probably does make sense, for people coming over from Windows) as long as we
don't lose the functionality of the editing keys (which are also supported by
kde and gnome apps, and in fact by many Windows apps) in the meantime.

Note that KDE and Gnome never had to make this decision because they don't have
the plethora of keybindings that Netscape has, and their keybindings aren't
chosen without regard to the standard Unix editing set, so the two sets aren't
mutually exclusive the way they are in Netscape.

Comment 15

19 years ago
... GNOME users can re-bind any menu shortcut in an intuitive way, on the fly,
and have it saved between sessions. Mozilla doesn't (can't?) do that so the
defaults in final release had better be acceptable to everyone.

For now, it doesn't matter. M18 is fine.

Comment 16

19 years ago
Mozilla users can rebind keys as well -- XBL bindings are part of CSS, and as
such, independantly specifiable for each user; XUL bindings and menu shortcuts
are set in the chrome, and it's pretty easy to change those, too though it may
not yet be possible to do it simply by changing a file in one's profile

We're not going to get keys that are acceptable to everyone.  That's quite
clear.  That's why they're configurable.

Comment 17

19 years ago
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [NEED INFO] → [nsbeta2-]

Comment 19

19 years ago
I attached a patch to change xulkey to control.

I am now going to work on a more important thing: enabling menu mnemonics and
menu access with Alt+letter keys.

I think the default should be changed to control now. People that want alt can
easily run a sed script trough the chrome files.

Comment 20

19 years ago
Marko: please see the bug this depends on, bug 23587.  The key will be settable
through style, and we're waiting for that.  Flipping the hardcoded values back
and forth just confuses and annoys people.  Let's do it the right way, with CSS.

There's also a bug (assigned to saari) on making the menu access key CSS
accessible, a very similar problem.
fyi: saari's css bugid is bug 21539. should this be made dependent on that bug,

Comment 22

19 years ago
Move to M20 target milestone.
Target Milestone: M18 → M20

Comment 23

19 years ago
Putting on [dogfood-] radar.
Whiteboard: [nsbeta2-] → [nsbeta2-][dogfood-]
adding ninoschka, as this would affect her UI work in Mail. over to keybd nav,
Component: XP Apps → Keyboard Navigation

Comment 25

19 years ago
OK, guess we're still waiting on Akkana for the plumbing.  I'll hold onto this
for awhile longer.

Comment 26

19 years ago
Don, if you want, you can assign it to me; I'll be making both binding sets in
order to test the plumbing in any case.

As to when we should flip the switch, I guess that still needs to be decided. 
If we want to flip the switch before beta2 and see if users complain, I could
trivially do that and make it a hidden pref for users who want to go back the
other way, then fix it "the right way" once the beta2 crunch is over.

Comment 27

19 years ago
*** Bug 26868 has been marked as a duplicate of this bug. ***

Comment 28

19 years ago
OK, you got it ...
Assignee: don → akkana

Comment 29

19 years ago
The current plan is to look at these key issues for M18.
Keywords: dogfood → correctness, nsbeta3
Whiteboard: [nsbeta2-][dogfood-]
Target Milestone: M20 → M18

Comment 30

19 years ago
setting to nsbeta3+
Whiteboard: nsbeta3+

Comment 31

19 years ago
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]

Comment 32

19 years ago
setting priority in status whiteboard
Priority: P3 → P2
Whiteboard: [nsbeta3+] → [nsbeta3+][p:2]


19 years ago
Priority: P2 → P4
Whiteboard: [nsbeta3+][p:2] → [nsbeta3+][p:4]


19 years ago
Blocks: 37233

Comment 33

19 years ago
The fix is in.  Default is Windows keybindings (alt for menu access, ctrl for
accelerator); if you want the classic unix bindings, put this in your user.js or
user_pref("ui.key.acceleratorKey", 18);
user_pref("ui.key.menuAccessKey", 0);
In contrast, Windows bindings (the default, so you don't need to set them) are:
user_pref("ui.key.acceleratorKey", 17);
user_pref("ui.key.menuAccessKey", 18);
Last Resolved: 19 years ago
Resolution: --- → FIXED
vrfy on linux commercial, 2000.08.22.08.

akkana and i have found some other related issues, but will file those
separately, since her fix here works.
really, vrfy this time.

Comment 36

7 years ago
Emacs is very customizable. It comes with Windows key modifications and there are OS modification files for other operating systems. There is OS integration available as well. Someone used to Emacs key combinations will use the default, while expecting other applications to behave like a native app. One may always choose old Netscape style key combinations or use Gecko style system integration.
Component: Keyboard: Navigation → User events and focus handling
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.