101046 - changing accelerator key (in debug prefs) no longer works

Status: NEW

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

Description

[Greg Onufer]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4+) Gecko/20010921
BuildID:    2001092114

I've been using Preferences->Debug->Accelerator Key = 18
and Menu access key = 0 for a short while now because I'm
an Emacs user and that allows me to use Emacs editing
keystrokes in the E-mail composer.  Starting yesterday
I noticed that Mozilla _thinks_ it's using Alt as the
accelerator key (the menus show it as the shortcuts)
but Control is what it's really using.  Alt-N does nothing
but Ctrl-N opens a new browser window.


Reproducible: Always
Steps to Reproduce:
1. Set preferences to 18/0 for the accelerator key, menu access key
2. Type Alt-N
3. Then type Ctrl-N

Actual Results:  For 2: Nothing happens.
For 3: Browser window opens.


Expected Results:  For 2: New browser window opens.
For 3: Nothing.


In some text entry boxes (like these in bugzilla-helper.html)
control-N does cursor movement (like in Emacs) and Alt-N still
does nothing.  So the behaviour isn't even consistent.  But almost
everywhere including e-mail message composition ctrl-n opens a
new window.

Comment 1

[Boris Zbarsky [:bzbarsky]]

ccing akkana

Comment 2

[Akkana Peck]

I just installed today's build, and my alt keybindings are still working.  Is it
possible that your prefs file got overwritten somehow?  Are you setting the
prefs via user.js, prefs.js, or the debug UI?  Check both prefs.js and user.js
to see if something got overwritten somehow.

Comment 3

[Greg Onufer]

It didn't work for 3 consecutive days of my "clobber" several-times-daily
builds but it is working again.  For a day it wasn't very consistent
and worked in some places, didn't work in others.  It's now very
consistent.  I guess this can be closed since "it works for me" now.

Answers to questions: no user.js, just prefs.js settings set via the
Preferences Debug UI.  The two settings in prefs.js existed when I was
having the problem and even the Menu GUI said "Alt" instead of "Ctrl"
even when it was using Ctrl instead of Alt.  Ghost in the machine.

Comment 4

[Greg Onufer]

More info... if I start "mozilla -P myprofile" it works as expected.  If I start
mozilla and it brings up the profile chooser and I choose the same profile then
the menus all refer to "Alt" but the only key that works is "Ctrl"... ie, it says
use "Alt-N" in the File menu but "Ctrl-N" is the key that actually works.

I've noticed this off and on since I closed this report but was never able to
figure out what was causing the difference in behavior until now.

Comment 5

[Akkana Peck]

The accel/menu access keys only get initialized once, AFAIK.  If they're getting
initialized before the profile manager picks a profile, then there may be no
opportunity to change them once the correct profile is loaded.  Hyatt?  Suggestions?

Comment 6

[Aaron Leventhal]

-> akkana

Comment 7

[Akkana Peck]

There's another bug on this -- IIRC the problem is that key bindings are loaded
before profiles, so if you have multiple profiles, by the time mozilla knows
your profile directory it's too late because key bindings have already been
loaded.  I think hyatt owns that bug (if not, he'll know who does).

The best fix, probably, would be to fix XBL so bindings could be loaded or
changed at any time, not just at startup; we have other bugs as well which
depend on that (e.g. UI for changing key bindings).

Comment 8

[bender2037]

Hi,

this bug still exits.
I'm using Mozilla 1.3a under Linux.

Comment 9

[Gunnar Kaestle]

See bug 89524, this here seems to be a duplicate.

Comment 10

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.