Closed Bug 22515 Opened 25 years ago Closed 24 years ago

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

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P4)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
Other
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: djoham, Assigned: akkzilla)

References

Details

(Keywords: platform-parity, Whiteboard: [nsbeta3+][p:4])

Attachments

(1 file)

patch to change xulkey from alt to control
933 bytes, patch
Details | Diff | Splinter Review 
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
etc...

Thanks

David
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... :-)
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
conflicts...
Assignee: german → don
Based on a discussion on the newsgroups
(to view thread click this link: news://news/387A68FF.32252996%40netscape.com)
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.
m16
Target Milestone: M16
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
Depends on: 23587
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.

KDE
http://developer.kde.org/documentation/standards/kde/standard-keys.html

GNOME:
http://developer.gnome.org/doc/tutorials/gnome-libs/using-the-gnome-app-framework.html#AEN789

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.

David
Target Milestone: M16 → M18
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)!

As a start, changes need to be made in:

nsMenuFrame.cpp
nsXULKeyListener.cpp

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.

Putting on [NEED INFO] radar.  How critical is this to Linux users for PR2?
Whiteboard: [NEED INFO]
akkana, pavlov --your thoughts?
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.

David
i agree with djoham@criadvantage.com, 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
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.
... 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.

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

We're not going to get keys that are acceptable to everyone.  That's quite
clear.  That's why they're configurable.
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [NEED INFO] → [nsbeta2-]
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.

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,
too?
Move to M20 target milestone.
Target Milestone: M18 → M20
Putting on [dogfood-] radar.
Whiteboard: [nsbeta2-] → [nsbeta2-][dogfood-]
adding ninoschka, as this would affect her UI work in Mail. over to keybd nav,
too.
Component: XP Apps → Keyboard Navigation
OK, guess we're still waiting on Akkana for the plumbing.  I'll hold onto this
for awhile longer.

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.
*** Bug 26868 has been marked as a duplicate of this bug. ***
OK, you got it ...
Assignee: don → akkana
The current plan is to look at these key issues for M18.
Status: NEW → ASSIGNED
Keywords: dogfood → correctness, nsbeta3
Whiteboard: [nsbeta2-][dogfood-]
Target Milestone: M20 → M18
setting to nsbeta3+
Whiteboard: nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard
Priority: P3 → P2
Whiteboard: [nsbeta3+] → [nsbeta3+][p:2]
Priority: P2 → P4
Whiteboard: [nsbeta3+][p:2] → [nsbeta3+][p:4]
Blocks: 37233
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
prefs.js:
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);
Status: ASSIGNED → RESOLVED
Closed: 24 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.
Status: RESOLVED → VERIFIED
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: