Closed Bug 55408 Opened 24 years ago Closed 24 years ago

Switch default Unix modifier key back to ALT

Categories

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

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

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: akkzilla, Assigned: alecf)

References

Details

(Whiteboard: [rtm-]) 

Switching from alt to ctrl had a number of bad side effects:
1. It confused people who have been using Netscape with alt bindings since the
beginning of time
2. There are quite a few conflicts with the longstanding Unix editing bindings
(which is the reason that we always used alt in the past): we have conflicts on
F, K, U, E, D, and W (W has been temporarily disabled).

The fix is trivial: change two lines in the default Unix pref file, and then we
probably also want to re-enable ^W, and the cut/copy/paste/undo/redo bindings on
the control keys (which were removed when we changed the default).  This is very
easy, doesn't affect a lot of code, and has been well tested (it was the default
up to a month or so ago, and lots of people are currently running with the prefs
set to use the old default; I get requests all the time from people who want to
know how to set those prefs since it's not yet documented anywhere.

The downside is that there would be no menu access key, just like there never
was one in past versions of Netscape.  But people who need/want menu access keys
or Windows-style accelerators can always change the pref, so accessibility isn't
impacted since people who need the functionality can still get it.

For future versions, we can try to make the switch easier and more transparent:
see bug 49909, from which this is being split off (and which has more discussion
about why switching from alt was a bad move).
Nominate for rtm.
Keywords: rtm
Alec ...
Assignee: don → alecf
Priority: P3 → P2
Whiteboard: [rtm need info]
I think we need to decide if we actually need to fix this.

Here's the thing. GNOME/KDE are moving towards the windows model of using
Ctrl-based shortcut keys... I just tried out a few gnome apps (gnumeric,
gcalendar) to see what they do.. and in fact they do exactly what mozilla does:
when the focus is in a text field, they use emacs-bindings, and when the focus
is outside the text field, they use the application bindings.

So personally I think we are doing exactly the right thing. If we want to be
really slick, we could somehow hide the shortcut keys in the menu dropdown when
a textfield has focus, but GNOME apps don't do this, and I've never heard anyone
complain, and I don't think that it's worth the effort anyway.

(moments later, after trying to reload this bug in bugzilla: )
In fact Communicator 4.x does not allow you to use shortcut keys when you're in
a text field. Try it: put focus in a text field and hit Alt-R - the page does
not reload, and your machine will beep.
Totally off topic, but Netscape 4.x will still allow page up/page down while in
form elements.  However, the problem isn't people using Gnome/KDE...  It's that
Netscape is one of the most used applications and people are used to how it
works.  This is for continuing users, not new users.

Changing back to alt as accelerator... okay, whatever, I know how to change
prefs.

"re-enable ^W, and the cut/copy/paste/undo/redo bindings on the control keys"

Bad idea, unless that's automatically turned off when I switch to ctrl as
accelerator. Since all that is done in xul/xbl, that's gonna need support in
that code.
*** Bug 55648 has been marked as a duplicate of this bug. ***
*** Bug 55652 has been marked as a duplicate of this bug. ***
I agree with Alec's assessment, certainly for RTM at this point.  Minus.
Whiteboard: [rtm need info] → [rtm-]
does someone else want to take this bug? The only way we're actually going to do
this is on a preference, but I wouldn't even know where to begin on this.
It's already on a preference, has been for a long time.  (See
http://www.mozilla.org/unix/customizing.html)  This bug is for changing the
default back.
*** Bug 59860 has been marked as a duplicate of this bug. ***
oh! doh. Ok then, I'm going to mark this WONTFIX.. because at least for
seamonkey, we're going to use Ctrl..
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
This is stupid!  How long would this take to fix?  All we're talking about is a
preference in the Edit Preferences menu which allows people to switch to the old
Netscape 2/3/4x behavior in UNIX.  All told, it would take, what?  An hour?  10
lines of code?  Is this really such a bad thing?
Benjamin, this bug is about the default value of that preference. I think there
is another bug on adding this preference to the preferences dialog, perhaps one
of the other cc's on this bug knows its #?
Hmm...  Good point.  I care less about this one.  (As long as it can be easily
changed, it's okay.)  Sorry, I was confused between the numerous bugs on this issue.
yes, to clarify, we are not "fixing" this based on a decision that we'll be 
using Control, not Alt to be consistent with GNOME, et al.

It would be nice to have an Advanced pref UI for this.. but that's a different 
bug.
*** Bug 61444 has been marked as a duplicate of this bug. ***
*** Bug 61444 has been marked as a duplicate of this bug. ***
*** Bug 61507 has been marked as a duplicate of this bug. ***
alecf wrote:
> at least for seamonkey, we're going to use Ctrl..
later:
> based on a decision that we'll be
> using Control, not Alt to be consistent with GNOME, et al.

If you cite "decisions", please also mention, where and how the decision has
been made.

vrfy wontfix
Status: RESOLVED → VERIFIED
I'd like to hear the rationale first.
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.