625151 - Alt key sometimes fails to open Menu bar

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[[e-mail]]

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][⌚️UTC+1]]

Does it happen on pages with Plugins like Flash? Or even on simple HTML pages? Do you have example URLs?

Comment 2

[[e-mail]]

(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][⌚️UTC+1]]

Can you please test in Safe Mode with all extensions disabled?

http://support.mozilla.com/en-US/kb/Safe Mode

Comment 4

[[e-mail]]

(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.

Comment 5

[Seungbeom Kim]

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] (he/him)(JST, +0900)]

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] (he/him)(JST, +0900)]

Okay, I see the cause, I'll post a patch.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

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]

The patch looks ok, but the test looks to pass even without the changes.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(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] (he/him)(JST, +0900)]

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] (he/him)(JST, +0900)]

Attachment: Patch

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] (he/him)(JST, +0900)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/eec3c6a55865

Comment 14

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

https://hg.mozilla.org/mozilla-central/rev/eec3c6a55865