2.42 KB, patch
|Details | Diff | Splinter Review|
Since mozilla has recently unified the key bindings across platforms, old unix/netscape users have been forced to align with the mac&windows/netscape user's bindings. However, since many people are using a combination of netscape and mozilla and switching back and forth, and others might have key bindings already set for Ctrl-Left/Ctrl-Right and others, this can present some problems. I know this is configurable with the prefs.js or user.js file, but it should be configurable in the Edit|Preferences dialog. (This would also allow unix users to use windows and macintosh machines more easily.) Can we make this a preference?
Akk said to assign this bug to either don or german. So here we go.
Assignee: matt → don
don's on sabbatical, so over to german. also cc'ing akkana.
Assignee: don → german
Component: Preferences → Keyboard Navigation
I'll confirm the bug: it's a valid request to ask for a pref UI for it, and it's certainly going to be confusing to a lot of Unix users who used our old client (I've already intercepted several questions about it on IRC, beginning about an hour and a half after I checked in the change to the Windows bindings!) We'll certainly need to make this prominent in the release notes, as well.
Status: UNCONFIRMED → NEW
Ever confirmed: true
would be nice to have this go in beta3, but, in case it doesn't, must relnote for beta3.
Severity: minor → enhancement
Agreed. We definitely need a substantial section in the release notes about the key binding changes between beta2 and beta3 in any case.
Adding relnote3 keyword.
Marking nsbeta3- while this sits with German. If this is reassigned to an engineer it should be evaluated again.
Handing German's bugs off to Don to decide.
Not sure what is going on with this bug. If it is assigned to an engineer it can be evaluated for nsbeta3, but assigned to german there is no meaning at this late date to nsbeta3. Marking -.
Meant to reassign to Don, at least so someone will look at it and think about it. We've gotten several complaints so far about the default bindings having changed in the mozilla dailies; it remains to be seen how many people will care in the actual beta/release.
Assignee: german → don
At this late date, it's not possible to make this more discoverable. Sorry.
Added to release notes: "Keyboard shortcuts use Windows and Mac OS conventions." Is that what you mean? Someone please confirm.. thanks.
To which some Unix users will reply: `I've never used Windows or Mac OS, and I've no idea what they use for keybindings -- so what good is it to tell me that?'
I suggested to Vera via mail (bugzilla wasn't responding at the time) that less confusing might be something on the order of: "Unix keyboard shortcuts now use control instead of alt as the modifier key, following the Windows convention." I'd like to see the prefs get into the release notes as well -- any chance of that? I.e.: ... Users who prefer to use the alt key can add the following prefs to their prefs.js file: user_pref("ui.key.accelKey", 18); user_pref("ui.key.menuAccessKey", 0);
I strongly agree with akkana. I follow moz very closely, and despite that have had no idea (until now) about the prefs workaround. If that could be indicated in the release notes it would be a great boon to Unix users (who generally don't mind mucking around in config files, as long as it is documented.
verah, in the relnotes for RTM, you could say, f'rzample (change/neaten up as needed :), The unix shortcut bindings are, by default, the same as the Windows bindings. In other words, the accelerator key is the Control key, and the menu access key (for mnemonics) is the Alt key. However, these default bindings are changeable. You can modify your prefs.js to change them. For example, user_pref("ui.key.accelKey", 18); This changes the accelerator key from Control (17) to Alt (18). user_pref("ui.key.menuAccessKey", 0); This changes the menu access key from Alt (18) to *none* (0).
This seems particularly bad to me. I'm not sure why the "mozkey" was changed. There are now lots of bad conflicts. For example, in the browser's urlbar, if I press Control-A to select all (as displayed in the Edit menu), it moves the caret to the beginning of the line since Control-A is also a keybinding for "beginning of line" The simplest, easiest, safest fix would be to switch the modifier key back. If we leave this as is, the menus are lying about keybindings actually working when they may or may not depending on whether a conflict exists or not. I don't understand why we have changed the modifier key from 4.x to seamonkey.
Whiteboard: [nsbeta3-][cut 0920]
There are quite a few other conflicts, too. I had to turn off ctrl-W because it conflicted with Close Window, and I'm really missing ctrl-W, which now works in text controls but not in the editor/mail compose. Some other conflicts are ctrl-F (which only brings up the find dialog if focus is in the browser window and not the urlbar), ctrl-K (which may go away when the "increase text size", binding is changed to +), ctrl-U in composer/mail compose, and ctrl-E and D if those have bindings (not sure what they are). Kathy and I both think this is confusing enough that it's worthy of RTM consideration. The fix, incidentally, is trivial: change two lines in the default Unix pref file (and turn ctrl-W back on, one line in the editor Unix bindings). I can do that (assign the bug to me if it's approved). It's been well tested: I've been running with these pref settings as dogfood for quite a while, and so have lots of other Unix people (I get requests via IRC and mail all the time asking how to change the bindings back to the old familiar non-conflicting ones).
Answer to question of putting the prefs in the RTM release notes: Yes, I can do that. I'll also try to get this into a couple of future docs, including an upgrade guide and a tips document.
nav triage team: we see 3 issues here: 1) making the pref to changing bindings discoverable (currently hidden). That is a feature request, so is a rtm-. That is what this bug was about originally. 2) add info to the release notes or help on how to change these hidden prefs. Vera is taking care of that, keyword relnoteRTM covers that. 3) there seems to be additional keybinding conflicts in Linux with what we are currently planning on doing (see Kathy Brade's comment 10/5). This could be a big problem, we should track this problem as a separate bug. Please create a new bug just for that issue.
changing title to Need exposed pref to change bindings: Unix vs. Windows to be more clear on what specifically is being handled in this bug.
Summary: Unix/Netscape bindings vs. Windows/Netscape bindings → Need exposed pref to change bindings: Unix vs. Windows
Whiteboard: [rtm-] → [rtm-] relnote-user
Removing myself from the list of cc's... this is in either the release notes or the upgrade guide; can't remember which.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Assignee: vishy → mcafee
nav triage team: Neither beta nor mozilla0.9 stopper, marking nsbeta1-, resetting target milestone
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla0.9 → ---
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
This patch simply adds two text field prefs with the values of the accelerator key and menu access key values. I was thinking about a radio button here, but ? mac uses different values, and we might not know about all the possible keyboard values ahead of time to present them in a radio button like that. This is a safe way to present the values for now, we can simplify this later and put it in a more-obvious pref pane at that time.
fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
thx, chris! tested using 2001.06.19.xx comm bits. on linux and winnt, the Debug General pref panel has 17 for the Accelerator key and 18 for the Menu access key [by default]. on mac, the same panel has 224 for the Accelerator key and 0 for the Menu access key. the panel contents are a bit clipped at the bottom, but filed a separate bug for that, bug 86780.
Status: RESOLVED → VERIFIED
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.