Last Comment Bug 625151 - Alt key sometimes fails to open Menu bar
: Alt key sometimes fails to open Menu bar
Product: Core
Classification: Components
Component: XP Toolkit/Widgets: Menus (show other bugs)
: Trunk
: x86 Windows 7
: -- normal with 1 vote (vote)
: mozilla13
Assigned To: Masayuki Nakano [:masayuki] (Mozilla Japan)
Depends on: 770773 1284825
  Show dependency treegraph
Reported: 2011-01-12 12:23 PST by
Modified: 2016-07-06 08:24 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch (4.62 KB, patch)
2012-02-07 20:26 PST, Masayuki Nakano [:masayuki] (Mozilla Japan)
no flags Details | Diff | Splinter Review
Patch (4.63 KB, patch)
2012-02-08 17:42 PST, Masayuki Nakano [:masayuki] (Mozilla Japan)
enndeakin: review+
Details | Diff | Splinter Review

Description 2011-01-12 12:23:20 PST
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.

Reproducible: Sometimes

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.
Comment 1 Henrik Skupin (:whimboo) 2011-01-12 12:38:01 PST
Does it happen on pages with Plugins like Flash? Or even on simple HTML pages? Do you have example URLs?
Comment 2 2011-01-12 12:41:23 PST
(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.
Comment 3 Henrik Skupin (:whimboo) 2011-01-12 12:45:12 PST
Can you please test in Safe Mode with all extensions disabled? Mode
Comment 4 2011-01-12 12:46:32 PST
(In reply to comment #3)
> Can you please test in Safe Mode with all extensions disabled?
> Mode

Will do, and will report back if the problem reproduces itself.
Comment 5 Seungbeom Kim 2011-06-21 16:49:07 PDT
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.
Comment 6 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-02-06 22:37:35 PST
Do you reproduce this bug only when the window is maximized and after the window activated by Alt+Tab from another application?
Comment 7 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-02-06 22:50:04 PST
Okay, I see the cause, I'll post a patch.
Comment 8 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-02-07 20:26:43 PST
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.
Comment 9 Neil Deakin 2012-02-08 12:45:21 PST
The patch looks ok, but the test looks to pass even without the changes.
Comment 10 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-02-08 16:51:43 PST
(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.
Comment 11 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-02-08 17:11:22 PST
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?
Comment 12 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-02-08 17:42:04 PST
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.
Comment 13 Masayuki Nakano [:masayuki] (Mozilla Japan) 2012-02-13 16:57:32 PST
Comment 14 Marco Bonardo [::mak] 2012-02-14 02:40:57 PST

Note You need to log in before you can comment on or make changes to this bug.