User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110112 Firefox/4.0b10pre
It's difficult to figure out the exact cause for this, as it seems to happen randomly, but the Alt key seems to occasionally stop working to open the Menu bar when pressed. It doesn't seem webpage-related, as sometimes while on the same page it'll work some times but not others, regardless of what part of the page has focus, and even if I switch to a new tab. Functionality usually restores itself within 5 minutes of browsing, but it's still a nuisance.
It's worth noting that this seems more likely to happen if the browser has only recently (~10 minutes or less) been started.
Steps to Reproduce:
Problem is random, seems impossible to reproduce intentionally.
Using the Arcane Persona, but have gone a few days without it to test if the problem persists, which it does.
Does it happen on pages with Plugins like Flash? Or even on simple HTML pages? Do you have example URLs?
(In reply to comment #1)
> Does it happen on pages with Plugins like Flash? Or even on simple HTML pages?
> Do you have example URLs?
It happens on all pages when it's occurring - HTML, flash, even blank, new tabs. As I said, while it's not working, I can switch tabs and it still won't work until a few minutes later, when the problem seems to resolve itself.
Can you please test in Safe Mode with all extensions disabled?
(In reply to comment #3)
> Can you please test in Safe Mode with all extensions disabled?
> http://support.mozilla.com/en-US/kb/Safe Mode
Will do, and will report back if the problem reproduces itself.
When the problem happens, any Alt-shortcuts such as Alt+F just rings the system bell without opening the menu. Is there a way to trace the system events that lead from the keypress to the system bell? That could really help the developers find out the cause of the bug.
Do you reproduce this bug only when the window is maximized and after the window activated by Alt+Tab from another application?
Okay, I see the cause, I'll post a patch.
Created attachment 595300 [details] [diff] [review]
There are two causes:
1. When a window is deactivated, mAccessKeyDown isn't reset. Therefore, the state still be true when the window is activated later.
2. When Alt key is down but the previous Alt key down was canceled by something, such situation is made by some other applications may send key events during deactivated, or our IME event handler of Windows' widget dispatches a key event for hacking menubar, the keydown handler of our menubar fails to set mAccessKeyDown true.
So, we should reset mAccessKeyDown and mAccessKeyDownCanceled at blur. And also, we should do better handling at keydown.
The patch looks ok, but the test looks to pass even without the changes.
(In reply to Neil Deakin from comment #9)
> The patch looks ok, but the test looks to pass even without the changes.
Why, I confirmed the test timed out without change.
The points of this bug are:
1. (!mMenuBarFrame->IsMenuOpen() && mMenuBarFrame->IsActive()) returns FALSE at blur if pressed Alt+Tab.
2. KeyDown() checks mAccessKeyDownCanceled before it sets mAccessKeyDown true even if mAccessKeyDown is false.
The test expects:
* mAccessKeyDown becomes true by first Alt keydown.
* mAccessKeyDownCanceled becomes true by Tab keydown (this is just an example, not happen actually, but this can be happen with other keys or mouse button).
* Fire blur event on the window during Alt keydown.
* The BACK_QUOTE keypress may happen if one or more IMEs are installed on the system. Even if it's not so, this might be happen with some other applications. This keydown event sets mAccessKeyDownCanceled true even if mAccessKeyDown is false.
* Finally, the last Alt key down event doesn't cause setting mAccessKeyDown true due to #2.
Oh, I tested it again without the change, the test passed. Something I changed after the confirmation made it so, hmm. Why did you think that the test has the bug?
Created attachment 595591 [details] [diff] [review]
Okay, I see. Our hacky code only dispatches keypress event but the test dispatches keyup which causes resetting the flags.