Steps to reproduce: 1. Load http://www.cs.hmc.edu/~jruderma/s/ 2. Press Alt+3 to focus the Google textbox, but release Alt before releasing 3. Result: The Google textbox gets focus, but the menu bar is also activated (focused?) and steals keystrokes until I hit the escape key. I run into this bug pretty often when using access keys on my start page.

See also bug 39721, Switching keyboard layout by typing alt+shift activates menu.

can you try the patch in that bug and see if it fixes both cases?

Changing "accesskey" in summary to "key", since this happens with alt+left and alt+right (back/forward) in addition to accesskeys.

Wait, this is not a bug, this is the expected behavior. Typing Alt by itself in Windows apps is supposed to activate the menu bar. Try your same page in IE. Marking invalid.

he didn't type alt by itself. he released alt before he released the key. REOPEN ie doesn't mess up.

Assigning to myself and moving pinkerton to cc. Ccing akkana for r and hyatt for sr. I forgot about the patch on bug 39721, and I haven't tried it. I'm not sure if that patch fixes this bug, but I know the patch on this bug fixes both bugs.

I heard that akkana isn't around, so pinkerton, can you review the patch instead?

My patch to bug 39721 doesn't fix this bug, and I don't find that the patch here fixes that one. I'll attach an updated patch to 39721 assuming this patch.

This patch seems to fix the alt+shift problem on a WinNT debug build. I'm testing by pressing Alt+Shift many times, and I see the menu bar get focus on an (optimized) nightly but not on my debug build. On the other hand, my patch breaks Alt+F. Withdrawing attachment 38017 [details] [diff] [review] from review while I try to figure out why.

Ok, let's try this again. Pinkerton and Hyatt, can you look at this patch?

*** Bug 86324 has been marked as a duplicate of this bug. ***

Accepting, since I have a patch.

Didn't get reviewed in time for 0.9.2, so pushing out to 0.9.3.

*** Bug 91032 has been marked as a duplicate of this bug. ***

The accesskey on your test page isn't working for me at all under win2k. I'm having the opposite problem with Alt+Left The menu bar gets activated when alt is released *after* the key. But I think there's a related fix, and one that will allow us to use Alt on Linux systems: Alt should only activate the menu bar when *no* mouse clicks or other keys occur between the alt key going down and it going up.

> The accesskey on your test page isn't working for me at all under win2k. Alt+3 on http://www.cs.hmc.edu/~jruderma/s/ works fine for me on WinNT. Perhaps you have focus in the URL bar (bug 64606)? > I'm having the opposite problem with Alt+Left > The menu bar gets activated when alt is released *after* the key. Same here. I don't know why Alt+Left has the opposite problem as Alt+3, but my patch (which I wrote before noticing that Alt+Left was different) seems to fix both problems. > But I think there's a related fix, and one that will allow us to use Alt on > Linux systems: Alt should only activate the menu bar when *no* mouse clicks or > other keys occur between the alt key going down and it going up. That's what the code I'm patching was trying to do. The problem was that the code was catching keypresses but not than keydowns. That's why (Alt, 3, lift Alt, lift 3) would focus the menu bar. Enabling Alt to focus the menu bar on Linux should be a separate bug, but I'd rather not do that. I've had focus get "stuck" in the menu bar many times without noticing it, and I'm sure new Windows users get confused about that all the time.

* Only fixes the case where the entire alt+click takes less than a second. See bug 91592, "nsMenuBarListener gets KeyDown events for autorepeated keypresses".

Jesse: enabling the menu access key focus on linux is what the "mAccessKeyFocuses" variable is all about; it's set from the pref "ui.key.menuAccessKeyFocuses" (which defaults to false on linux and true on other platforms). It looks like in your patch you've removed the checks for menuAccessKeyFocuses. Maybe I'm not understanding the patch (I haven't applied it and tried it, my tree is still building) and it's correct that menuAccessKeyFocuses is no longer needed in this part of the code. Can you explain why that is? Can it be removed entirely (including the variable and the pref), or only in this one clause?

The mAccessKeyFocuses check in KeyPress was just there to make the Alt+F check faster in the case where mAccessKeyFocuses is true. But since I completed the change of the meaning of mAccessKeyDown from "Alt is depressed" to "Alt is depressed and nothing else interesting has happened since it was depressed", the optimization was causing Alt+F not to work at all, so I removed the optimization. mAccessKeyFocuses is still used in other parts of the code so that pressing Alt by itself on Linux doesn't focus the menubar. Changing that behavior on Linux would be a different bug, and one I'd probably vote against.

looks ok, but i'll leave it to akkana to verify if it does the correct thing on linux with respecting the "ui.key.menuAccessKeyFocuses" pref. r=pink.

Looks good, everything still works as expected. r=akkana.

sr=blake

Checked in, no?

See also bug 94175, ALT-TAB to mozilla focus to File menu. I don't think I caused that bug, but it's possible that I did.