Alt key sometimes fails to open Menu bar

RESOLVED FIXED in mozilla13

Status

()

Core
XP Toolkit/Widgets: Menus
RESOLVED FIXED
6 years ago
10 months ago

People

(Reporter: jaitsu@ymail.com, Assigned: masayuki)

Tracking

(Depends on: 1 bug)

Trunk
mozilla13
x86
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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.
Does it happen on pages with Plugins like Flash? Or even on simple HTML pages? Do you have example URLs?
(Reporter)

Comment 2

6 years ago
(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?

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

Comment 4

6 years ago
(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

6 years ago
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.
Status: UNCONFIRMED → ASSIGNED
Component: Menus → XP Toolkit/Widgets: Menus
Ever confirmed: true
Product: Firefox → Core
QA Contact: menus → xptoolkit.menus
Version: unspecified → Trunk
Created attachment 595300 [details] [diff] [review]
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.
Assignee: nobody → masayuki
Attachment #595300 - Flags: review?(enndeakin)

Comment 9

5 years ago
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]
Patch

Okay, I see. Our hacky code only dispatches keypress event but the test dispatches keyup which causes resetting the flags.
Attachment #595300 - Attachment is obsolete: true
Attachment #595591 - Flags: review?(enndeakin)
Attachment #595300 - Flags: review?(enndeakin)

Updated

5 years ago
Attachment #595591 - Flags: review?(enndeakin) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/eec3c6a55865
Whiteboard: [inbound]
Target Milestone: --- → mozilla13
https://hg.mozilla.org/mozilla-central/rev/eec3c6a55865
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]

Updated

a year ago
Depends on: 770773

Updated

10 months ago
Depends on: 1284825
You need to log in before you can comment on or make changes to this bug.