Closed Bug 49909 Opened 24 years ago Closed 23 years ago

Need exposed pref to change bindings: Unix vs. Windows

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement, P5)

x86
Linux
enhancement

Tracking

()

VERIFIED FIXED
Future

People

(Reporter: ben, Assigned: mcafee)

References

Details

(Keywords: helpwanted, Whiteboard: [rtm-] relnote-user)

Attachments

(1 file)

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
Keywords: nsbeta3
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.
Keywords: relnote3
Marking nsbeta3- while this sits with German.  If this is reassigned to an 
engineer it should be evaluated again.
Whiteboard: nsbeta3-
Handing German's bugs off to Don to decide.
Whiteboard: nsbeta3-
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 -.
Whiteboard: nsbeta3-
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
Whiteboard: nsbeta3-
Whiteboard: [nsbeta3-][cut 0920]
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?'
Keywords: relnoteRTM
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.
Keywords: nsbeta3
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).
Keywords: rtm
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.
Whiteboard: rtm-
Whiteboard: rtm- → [rtm-]
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
mcafee, nsbeta1
Assignee: vishy → mcafee
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9
Priority: P3 → P5
nav triage team:

Neither beta nor mozilla0.9 stopper, marking nsbeta1-, resetting target milestone
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla0.9 → ---
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
Status: NEW → ASSIGNED
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.
sr=alecf
r=matt
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: