(alt-e), a works (selects everything on the page) alt-(e,a) doesn't. Furthermore, if there is an alt-A accesskey on the page, alt-(e,a) activates the accesskeyed element. Another observation that may or may not be the same problem: pressing alt-e,a quickly doesn't work. I'm not sure if I'm lifting the alt key before or after pressing 'a' in this case. Mozilla nightly build 2000090908 on Win98.

This isn't a problem in the event system (at least, it's not known to be). Moving to XPMenus.

I see what you mean, but no time for this in the current release cycle ->Future

I think hyatt made a change last week so that one must be explicit in what modifiers are allowed for different actions (like key presses and mouse clicks) to go through the filters. I think I read about this in n.p.m.xpfe.

adding hyatt per heikki's comment

Nominating for nsbeta1 because this slows me down in an annoying way when I'm using menus with the keyboard. Also adding access keyword and ccing aaronl.

C'est moi.

Hyatt, can you expand on Heikki's comments at all? The Alt+<key> press isn't getting to the menu listener. I've been trying to track this down, but haven't had much luck yet. Oh wait, no, I haven't had _any_ luck yet.

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

I run into this bug frequently, because I've memorized several menu shortcuts and can hit them quickly enough that it's hard to hold Alt down for just the right amount of time.

In a little more detail, the problem that I mentioned before is that nsMenuListener::KeyPress() doesn't get called if Alt is down. If Alt isn't down, everything gets called as expected. Anyone care to figure out why? I'll take another shot at it, but from what I remember from last time I had absolutely no luck.

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

Hrm. Maybe it's getting eaten by the menu bar listener.

Sorry; I'm no Mozilla hacker. But is it anything to do with an earlier fix, resulting in version 1.51, to solve bug 71326?

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

Yes, it's getting eaten by the menu bar listener and by page accesskeys. Alt+EF opens the edit menu and then opens the file menu. Also, Alt+DZ at http://www.cs.hmc.edu/~jruderma/s/ goes to Mozillazine (Alt+Z is an accesskey in the page).

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

I have a fix. nsMenuListener::KeyPress wasn't getting called because nsMenuListener::KeyDown was dismissing the menu incorrectly. This fix is similar to part of my fix for bug 79898, "Alt+key activates menu bar if alt released before key": both patches remove the same section of code from different files. Fixing nsMenuListener::KeyDown fixes this bug but leaves the problem that page accesskeys win over accesskeys in open menus. It's correct for page accesskeys to win over accesskeys for main menu titles, but when a menu is open only the menu should see key events. I'm still working on this problem.

Comment on attachment 91160 [details] [diff] [review] patch: fixes the bug except for when the page has accesskeys r=akkana, but please update the "Since a menu is open" comment since when we dismiss the menu we still get there.

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

Comment on attachment 91160 [details] [diff] [review] patch: fixes the bug except for when the page has accesskeys sr=kin@netscape.com

Comment on attachment 91160 [details] [diff] [review] patch: fixes the bug except for when the page has accesskeys a=asa (on behalf of drivers) for checkin to 1.2a

checked in