OK, this one might be tought to explain. It's similar to Bug 18598, but not a duplicate. When you press Alt+Tab on Windows, the "task switcher" comes up and allows you to cycle through all open windows. If you press Esc to cancel out of this, which I often do, the menu becomes active when Alt is released. Steps to Reproduce: 1. Open Mozilla and at least one other app 2. Press Alt+Tab - "task switcher" comes up 3. Keep Alt held down, and press Esc - "task switcher" is dismissed 4. Release Alt - menu is activated Actual Results: Menu is activated when Alt is released. Expected Results: Menu does not become active. My guess is that in order to address Bug 18598, flags are being set somewhere along the line when Alt is pressed, and cleared when the window loses focus. But when the "task switcher" appears, the window never receives a WM_KILLFOCUS, so the flag will never be cleared. Can you capture a Tab keydown message when Alt is pressed, before the "task switcher" appears? If so, then the flag should be cleared when the window receives a Tab keydown and the Alt_is_down (or whatever) flag is set. BuildID: 2000022508 WinNT 4 sp5

ohhhh hyatt ;)

Turns out what I described is the case, and it's already programmed into nsMenuBarListener.cpp (currently lines 143-145). The problem is that a window won't receive the Tab keydown in an Alt+Tab keydown. I'm working on a solution for this. It won't be pretty at first, but hopefully once I get it working, someone can guide me into making it a Windows-specific change.

Man, I wish I knew C++. I've got the code written and it would work, if I could just get it to compile. Let me describe what has to be done instead. All of this takes place in and around nsMenuBarListener.cpp. This is a WIN32-specific fix. 1. in nsMenuBarListener::KeyDown when mAltKeyDown is set, set a keyboard hook using: (HHOOK) hKeyboardHook = SetWindowsHookEx(WH_KEYBOARD, KeyboardProc, NULL, GetCurrentThreadId()). 2. KeyboardProc should consist of something along the lines of the following: if (code < 0) // this isn't for us return CallNextHookEx(hKeyboardHook, code, wParam, lParam); if (mAltKeyDown && wParam == NS_VK_ALT) // Alt+Tab being pressed - the Tab keydown will never make it to the window mAltKeyDown = PR_FALSE; CallNextHookEx(hKeyboardHook, code, wParam, lParam); // call the next hook in line return 0; // don't eat the keypress 3. in nsMenuBarListener::~nsMenuBarListener free the hook: if (hKeyboardHook) { UnhookWindowsHookEx(hKeyboardHook); hKeyboardHook = NULL; } ps. My problems with compiling revolved around either a) getting SetWindowsHookEx to recognize a function within nsMenuBarListener (eg. nsMenuBarListener::KeyboardProc), or else getting a non-member function to access the mAltKeyDown flag (the mAltKeyDown = PR_FALSE part in #2) in the particular instance of nsMenuBarListener. If someone could help a slightly confused C programmer out, I'd be really grateful.

Downloaded build 2000031208 and it appears to have been fixed.

yup! verif w/opt comm winNT bits, 2000.03.28.09.

Two points: Firstly, it doesn't work on my Win95 Build ID 2000051210 Secondly, would the WM_CANCELMODE message help you out?

This works fine for me on NT using the May 15 build. Are you sure?

It's a Win9x specific problem: Windows NT reflects key events during an ALT+TAB operation. However, as soon as you press TAB, Windows 9x hides all subsequent key events until the ALT key release event. Both Win9x and NT send a WM_CANCELMODE message between the ALT key press and release.

I just _love_ how Win32 is implemented the same across all Windows platforms. It makes life so easy! So should this bug be re-opened?

Win95/Win98 problems -> bug 94175.