89524 - Change accelerators from Ctrl to Alt does work with multiple profiles (work around, use -P)

Status: NEW

(Core :: XUL, defect)

Description

[Ninoschka Baca]

Build 2001-07-05-10: Linux RH 6.2

Overview: I tried to change my accelerators on linux from Ctrl to Alt but no
change seemed to occur.

Steps to reproduce:
1. Select Edit|Preferences
2. Go to Debug panel and change
- Accelerator Key from 17 to 18
- Menu acess key from 18 to 0
3. Exit/Restart and choose a profile using the Profile Manager

Actual Results: The underlines still appear for the top menu items such as File,
Edit, View etc... Checked the preferences and it displays the new values 18 and
0. Alt+Q does not work and Ctrl+Q quits which is wrong.

Workaround: Instead of using the Profile Manager in step #3, use the command
line  with the -P flag (i.e. ./netscape -P qatest20). Now the top menu items are
not underlined and Alt+Q quits the application.

Comment 1

[Ninoschka Baca]

Thanks to Seth for suggesting the "-P" option which helped narrow down this bug.

Comment 2

[(not reading, please use [e-mail] instead)]

here's what I think is going on:

the prefs ("ui.key.accelKey", "ui.key.menuAccessKey") get initialized early, in
this case when the profile manager UI comes up.

this happens before nbaca chooses a profile (and loads another prefs.js), so the
default values are used.

perhaps we need some pref callbacks so that these values get updated when the
prefs change?

there might be other prefs listed on
http://www.mozilla.org/unix/customizing.html that have the same problem.

Comment 3

[Akkana Peck]

I'm fairly sure that an earier version of this code did use pref callbacks.  But
there's no callback code there now, either in nsXBLPrototypeHandler.cpp nor
nsMenuFrame.cpp nor nsMenuBarListener.cpp.  They should all have pref changed
callbacks.

Comment 4

[Kathleen :Brade]

Conrad may have some insight on this bug (since he's been in the profile picker 
recently).

Comment 5

[joki (gone)]

This is more of a menu/accelerator bug, not event handling.

Comment 6

[John Morrison]

actually, this sounds like it's entirely a profile and preferences issue.

Comment 7

[Akkana Peck]

Perhaps, except in that it would be really nice to be able to change key
bindings some time other than startup time.  If we ever get a key binding UI,
it's going to look bad if we have to tell the user to restart to bring the new
bindings into effect.  But that arguably should be a separate bug.

Comment 8

[Conrad Carlen (not reading bugmail)]

It's neither a prefs nor a profile problem. According to this, the problem is in
a client of the prefs service (menus):

> there's no callback code there now, either in nsXBLPrototypeHandler.cpp nor
> nsMenuFrame.cpp nor nsMenuBarListener.cpp.  They should all have pref changed
> callbacks.

Changing component.

Comment 9

[Nathan Kurz]

Just to update, the problem still exists.

// from user.js: 17 control, 18 alt, 224 meta
user_pref("ui.key.accelKey", 18);
user_pref("ui.key.menuAccessKey", 224);

If the profile manager window is avoided (start with "-P default"), Alt is the
accel key as I desire, and Meta operates the menus.  If at start the profile
manager window comes up (using an empty "-P" to force the profile manager), the
accelKey is reset to Cntl and Alt accesses the menus.  In the menus, however,
the hot key is still listed as "Alt-", although this is incorrect.

Bug #101046 appears to be a duplicate of this, but reaches a different
conclusion about the cause.  Is the conclusion in comment #8 still thought to be
valid?  Or is that conclusion possibly the inversion of the bug:  ie, why the
menus show user.js value but do not operate accordingly?

Comment 10

[Gunnar Kaestle]

Mozilla/5.0 (X11; U; Linux i586; de-AT; rv:1.3b) Gecko/20030203

user.js:
user_pref("ui.key.accelKey", 18);
user_pref("ui.key.menuAccessKey", 0);

After a couple of hours, the key switches back from Alt -> Ctrl, although the
menu shortcuts are still labeled 'Alt + Letter'. 
Runtime of mozilla ~4h, cpu time  ~8min

Im using two profiles, a standard and a test user, but both have the same
user.js expansion of the preferences.