Jason Goodman Reporter
	Description • 23 years ago

Several major useability problems in Mozilla on Unix are related to the use of
the control-key as the default accelerator key, rather than the "alt" key, which
was used in NS4.  Former NS4 users must re-train themselves for every shortcut
they commonly use.  In addition, there are some serious conflicts between
control-keys used as menu-bar shortcuts, and control-keys used as EMACS editing
commands.  See bug 96310 and bug 77976.

These problems can be solved by changing the pref ui.key.accelKey from ctrl to
alt, as described in http://www.mozilla.org/unix/customizing.html.  I suspect a
substantial majority of Unix users will want to do this, but many of them will
not know the feature exists, and many people who find it will be intimidated by
the cryptic text prefs file.

This pref is so useful and so non-obvious that it should be included in the
Edit/Preferences... dialog box -- the Advanced section is an okay place, in lieu
of a "global preferences" section which acts across Mozilla components.

If this can't be done, the help documentation needs to explain more clearly how
to edit the prefs file.

	sairuh (rarely reading bugmail)
	Comment 1 • 23 years ago

yep, this already exists: go to the Debug panel [the toplevel one labelled
General Debug]. at the bottom of the panel is a section for setting the
accelerator and menu access keys.

	Jason Goodman Reporter
	Comment 2 • 23 years ago

That's a *really* stupid place for it.  This has nothing to do with enabling
debugging output, which is what almost all of the other prefs in that section
do.  It's debugging-related only in the sense that it provides a work-around for
a bug.

The "debug" section seems to be intended for the use of mozilla developers. I
assumed this section would not exist in production code designed for naive users
-- most of the variables there are totally inappropriate for day-to-day use.

Choosing the accelerator key by numeric keycode is also not appropriate for
general users -- the dialog box should have, say, radio buttons for choosing
between "control", "alt", the stupid useless "windows" and "menu" keys, maybe
"option" and "command" (for Macs), and "other", where "other" enables a text box
for inputting keycode number.
You're right that the basic function is there, but it's not implemented in a way
which most users can find or understand how to use.  Maybe this should be
flagged for repair at some later date, but I don't think it's "Resolved".

	Chris McAfee
	Comment 3 • 23 years ago

Jason:  I wrote the pref you're complaining about.  Yeah
it needs some prettying up and a better pref pane, but ?
at the time it was a power-user feature and I just plopped it
there with comments that we should fix this up later.
How about a patch?  Let's fix this.  There's a bunch of
platform-specific issues, e.g. mac does some stuff differently,
it is not a trivial fix to pretty this option up.

	Akkana Peck
	Comment 4 • 23 years ago

It sounds like we all agree that the point is valid (we should have an exposed
pref for this, not just an obscure debug one which requires knowledge of the
nonstandard charcodes in our event system) so I'm reopening the bug.  (I too
would like to see it exposed.)

Re the nontriviality and platform differences: I'm not familiar with the prefs
window ui code: is there a way to show/hide buttons based on JS?  It would be
easy to whip up backend JS to handle setting things according to platform (I
could do that part if needed), but we'd want to have different UI as well (e.g.
offer a button that says "cmd" for the mac).

	Chris McAfee
	Comment 5 • 23 years ago

resummarizing.  agree with re-opening.

	sairuh (rarely reading bugmail)
	Comment 6 • 23 years ago

okay, confirming as rfe.

	Samir Gehani Assignee
	Comment 7 • 23 years ago

Moving to mozilla0.9.7.

	Samir Gehani Assignee
	Comment 8 • 23 years ago

-> mozilla0.9.9

	Samir Gehani Assignee
	Comment 9 • 23 years ago

Should this go into the ``Advanced'' panel for now (till (and if) we have an
``Accessibility'' panel)?  Aaron, any opinions?

	Akkana Peck
	Comment 10 • 23 years ago

I'm not Aaron, but I'd like to see it exposed in the advanced panel.  We can
always move it later if we get a key binding panel.

	Aaron Leventhal
	Comment 11 • 23 years ago

Sounds like a good plan to me.

	Peter Trudelle
	Comment 12 • 23 years ago

nsbeta1- per Nav triage team.  This is not needed for MachV.

	Samir Gehani Assignee
	Comment 13 • 23 years ago

-> Future

	sairuh (rarely reading bugmail)
	Comment 14 • 22 years ago

nominating for buffy.

aaronl/akkana, know anyone willing to take this on?

	Paul Wyskoczka
	Comment 15 • 22 years ago

nsbeta1- per the nav triage team.

	Robert Kaiser
	Comment 16 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 17 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 18 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 19 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 20 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 21 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 22 • 15 years ago

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

	Robert Kaiser
	Comment 23 • 14 years ago

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420