Stewart Reporter
	Description • 22 years ago

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021206
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030303

When the user preferences are set such that the "meta" (or "alt") key is used
for keyboard shortcuts instead of the "control" key, the menus properly loose
their underlines and special bindings for the "alt" key, but none of the
shortcuts work.  (I.e. Alt-W does not close, Alt-T does not create a new tab,
etc.)  The menus are properly updated, and the normal (Control-?) shortcuts
don't work when set, so I assume the preference name has not changed.

Reproducible: Always

Steps to Reproduce:
1. Add the following two lines to your prefs.js:
user_pref("ui.key.accelKey", 18);
user_pref("ui.key.menuAccessKey", 0);

2. Start Mozilla.
3. Press Alt-T, Alt-N, Alt-O, Alt-Shift-L, or some other shortcut.

Actual Results:  
Nothing.

Expected Results:  
Performed the indicated action, perhaps?
Alt-T should open a new tab.
Alt-N should open a new window.
And so on.

This worked under 1.2.1.

Linux 2.4.20
libc 2.3.1
gcc 3.2.1
Any theme (tested with Classic and Modern, as included in CVS)
WindowMaker 0.80.1 (should not be relevant)

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 22 years ago

akkana, did we change the pref names or something?  The debug gui no longer
seems to work....

	Simon Montagu :smontagu
	Comment 2 • 22 years ago

Is this a dupe of bug 89524? Reporter, have you started using multiple profiles?

	Stewart Reporter
	Comment 3 • 22 years ago

No, it's not a duplicate, and I have only one profile.
(For example, the underlines for the menu shortcuts _do_ disappear from the menu
bar, and all the shortcut hints are also properly changed.)

	Akkana Peck
	Comment 4 • 22 years ago

Alt-T (new tab in browser) and Alt-W (close window) are working fine for me in a
2003030308 build. I have multiple profiles but I always start up with
/path/to/mozilla -splash -Pprofilename to get around bug 89524.  I set my
keybinding prefs in user.js.  I can't think of anything nonstandard I'm doing.

Boris, did you see this too?  Reporter (and anyone else who can reproduce it),
can you try moving your .mozill aside, creating a fresh single profile, and then
changing only those two prefs, and see if it still happens?  I suspect a profile
problem of some sort.

	Akkana Peck
	Comment 5 • 22 years ago

See bug 193025 for another case where someone says that prefs that used to work
are suddenly being ignored, and no profile manager is involved, and most people
don't see the problem.

Could something have changed recently in prefs to introduce a timing-related bug
reading prefs at startup?

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 22 years ago

Akkana, I couldn't even get the UI to affect a change to the accel key (in spite
of a restart), and I didn't bother messing with the prefs by hand.  So I don't
know whether I see the bug, since I can't create the conditions necessary to
test it.

	Stewart Reporter
	Comment 7 • 22 years ago

I modified the prefs.js file directly.

It appears this bug only occurs when using the xlib toolkit.
Here are the ./configure parameters I used to compile mozilla:
 --prefix=/usr/local/mozilla-CVS --enable-toolkit-xlib --enable-def
ault-toolkit=xlib --disable-ldap --enable-crypto --enable-extensions --disable-i
nstaller --enable-strip

It also appears there are other input and display problems when using the xlib
toolkit.  (Keyboard typing to select a link and the "file open" display are
examples.)

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 8 • 22 years ago

cc'ing gisburn as this is apparently an mozilla-xlib issue

	Roland Mainz Assignee
	Comment 9 • 22 years ago

Taking myself...

	Gervase Markham [:gerv]
	Comment 10 • 19 years ago

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

	Gervase Markham [:gerv]
	Comment 11 • 19 years ago

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.