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.

ccing akkana

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.

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.

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.

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?

-> akkana

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).

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

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

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.