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...
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.
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...
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
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 email@example.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
Target Milestone: M20 → M18
setting to nsbeta3+
adding the brackets in the status
Whiteboard: nsbeta3+ → [nsbeta3+]
setting priority in status whiteboard
Priority: P3 → P2
Whiteboard: [nsbeta3+] → [nsbeta3+][p:2]
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
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.
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
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.