Closed Bug 262894 Opened 20 years ago Closed 20 years ago

Assistive technology hotkeys that use Alt key trigger Mozilla menu bar

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: aaronlev, Assigned: aaronlev)

References

Details

(Keywords: access)

Attachments

(1 file, 2 obsolete files)

Ignore WM_KEYUP VK_MENU
607 bytes, patch
aaronlev
: review+
bryner
: superreview+
Details | Diff | Splinter Review 
Steps:
1. Run Window-Eyes and Mozilla
2. Press Alt+Enter
3.
Steps:
1. Run Window-Eyes and Mozilla
2. Press Alt+Enter

What happens:
Mozilla focuses menu bar
(Window-Eyes might say "action not available" -- that's not relevant to this bug)

What should happen:
Mozilla does not focus menu bar.
This Windows-Eyes?  http://www.gwmicro.com/products/
Dean, yes :)
I haven't downloaded the demo yet, but are you sure this is our bug?  If we get
an Alt keypress we process it.  My first suspicion is that Window-Eyes is not
eating the Alt keypress properly.
Other apps don't have this problem with Window-Eyes, but we are getting the same
keypress events that we do when alt is pressed by itself: WM_SYSKEYDOWN for the
alt key, wparam = 0x12, lparam = 0x20380001 followed by WM_SYSKEYUP for the alt
key, wparam = 0x12, lparam = 0xc0380001 There must be some other message we
should be listening to in order to decide that alt is supposed to focus the menu
bar.

Window-Eyes is eating the keypress in between, but it's not eating the alt
keypress events. It wouldn't be able to eat the alt down event anyway, since it
doesn't know what key, if any will be pressed with it. And we need the alt up
event to clear the mIsAltDown flag.

I was thinking there might be some other way to know that the menubar should be
activated.
> And we need the alt up event to clear the mIsAltDown flag.
Sorry, I guess we don't need that after all. The next keypress will clear that.
Keywords: access
Attachment #166162 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #166162 - Flags: review?(emaijala)
Do you see any WM_CANCELMODE messages?
(In reply to comment #9)
> Do you see any WM_CANCELMODE messages?

No, I just tested and those aren't fired around these key events.
Attachment #166162 - Flags: review?(emaijala) → review+
(In reply to comment #5)
>There must be some other message we should be listening to in order to decide
>that alt is supposed to focus the menu bar.
Pressing ALT+TAB on Windows 95 I typically see the following sequence:
WM_SYSKEYDOWN (Alt)
WM_CANCELMODE
WM_CANCELMODE
0x0118
WM_KEYUP (Alt)
whereas on Windows 2000 I see this sequence:
WM_SYSKEYDOWN (Alt)
WM_SYSKEYUP (Tab)
WM_KEYUP (Alt)
Does Window-Eyes eat the keyup messages too?
Window-Eyes is not eating the up for the alt, because of our use of
peekmessage/noremove. That's the problem this patch gets around. If Window-Eyes
did eat the alt when it should, we wouldn't need the patch.
Oh, I should read comment 5 more carefully... so you're saying WindowEyes is
eating both keydown and keyup for the Enter key, which means we only get to see
the keydown and keyup for the Alt key, and nothing else?
(In reply to comment #13)
> Oh, I should read comment 5 more carefully... so you're saying WindowEyes is
> eating both keydown and keyup for the Enter key, which means we only get to see
> the keydown and keyup for the Alt key, and nothing else?

Correct. And they say they can't eat the up of the alt for us, for various
reasons. The key eating code has been baked into Window-Eyes for so long that
they don't want to change it just for Mozilla, because of the risk of messing up
other applications.
Actually it wasn't that I wanted them to eat the up of the Alt, I would have
preferred for them not to eat the up of the Enter. But without the source code
to DefWindowProc I can't see how it would know not to start the menu loop...
(In reply to comment #15)
> Actually it wasn't that I wanted them to eat the up of the Alt, I would have
> preferred for them not to eat the up of the Enter. But without the source code
> to DefWindowProc I can't see how it would know not to start the menu loop...

They don't want to change their code since it works with 1000s of programs by
now. If they didn't eat the up of some keys that they eat now, it could cause a
lot of programs to suddenly recognize those keys as being pressed when they
don't right now.

Any other suggestions?
Neil, I checked into some other assistive technologies and this is not a
Window-Eyes specific problem. It also happens with ZoomText.

We need to solve this problem. If you want we can run this new code only when a
screen reader is present. It would not perform the keystroke validity check in
most cases.

Please let me know what you prefer -- I need this fix for my beta testers.
Summary: Window-Eyes hotkeys that use Alt key trigger Mozilla menu bar → Assistive technology hotkeys that use Alt key trigger Mozilla menu bar
I should add that the proposed fixed also solves the problem for ZoomText.
Eureka!
When the Alt key is supposed to activate the menu, it's a WM_SYSKEYUP message.
When it's not supposed to activate the menu, it's a WM_KEYUP message.
Tested on Windows 2000, Windows 95, and on Windows 98SE with ZoomText.
So, not only does this patch fix this bug, but it also fixes the 9x alt-tab
bug.
The other approach is to determine the alt state from whether the message is a
WM_SYSKEY* message but that would require changes to the menu bar listener.
Comment on attachment 167733 [details] [diff] [review]
Ignore WM_KEYUP VK_MENU

Neil, that was magic -- thanks! Can you put in a comment explaining the new
condition? Who should we flag for sr=?
Attachment #167733 - Flags: review+
This seems so simple, and right, that it almost hurts.  Nice!
Comment on attachment 167733 [details] [diff] [review]
Ignore WM_KEYUP VK_MENU

Aaron, as for your comment, how about "Ignore VK_MENU if it's not a system key
release, so that the menu bar does not trigger"?
Attachment #167733 - Flags: superreview?(rbs)
That sounds good. I you want add an additional line explaining when it's not a
system key release

// Ignore VK_MENU if it's not a system key
release, so that the menu bar does not trigger
// This helps avoid triggering the menu bar for alt key accelerators used in
assistive technologies such as Window-Eyes and ZoomText, and when using Alt+Tab
Attachment #167733 - Flags: superreview?(rbs) → superreview+
The Windows 9x bugs sound like bug 97014, bug 94175 and bug 93877. Should we
close those?
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Attachment #166162 - Attachment is obsolete: true
Attachment #166162 - Flags: superreview?(neil.parkwaycc.co.uk)
I wonder if, given bug 347010, we could change the fix such that DHTML applications running in FF can still capture the alt-keyup?
(In reply to comment #27)
> I wonder if, given bug 347010, we could change the fix such that DHTML
> applications running in FF can still capture the alt-keyup?
> 

My comment appears bogus actually. Sorry. (see: https://bugzilla.mozilla.org/attachment.cgi?id=231767)
Depends on: 347010
Depends on: 708936
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: