Assistive technology hotkeys that use Alt key trigger Mozilla menu bar

RESOLVED FIXED

Status

()

Core
Keyboard: Navigation
RESOLVED FIXED
14 years ago
5 years ago

People

(Reporter: Aaron Leventhal, Assigned: Aaron Leventhal)

Tracking

({access})

Trunk
x86
Windows XP
access
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

14 years ago
Steps:
1. Run Window-Eyes and Mozilla
2. Press Alt+Enter
3.
(Assignee)

Comment 1

14 years ago
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.

Comment 2

14 years ago
This Windows-Eyes?  http://www.gwmicro.com/products/
(Assignee)

Comment 3

14 years ago
Dean, yes :)

Comment 4

14 years ago
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.
(Assignee)

Comment 5

14 years ago
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.
(Assignee)

Comment 6

14 years ago
> 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.
(Assignee)

Updated

14 years ago
Keywords: access
(Assignee)

Comment 7

14 years ago
Created attachment 166161 [details] [diff] [review]
If we don't see a real key down event after a PeekMessage/NO_REMOVE sees a keydown, that means the key combo is being swallowed by an external app, so we should suppress the keyup
(Assignee)

Comment 8

14 years ago
Created attachment 166162 [details] [diff] [review]
If we don't see a real key down event after a PeekMessage/NO_REMOVE sees a keydown, that means the key combo is being swallowed by an external app, so we should suppress the keyup

The patch is mostly comments.
Attachment #166161 - Attachment is obsolete: true
(Assignee)

Updated

14 years ago
Attachment #166162 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #166162 - Flags: review?(emaijala)

Comment 9

14 years ago
Do you see any WM_CANCELMODE messages?
(Assignee)

Comment 10

14 years ago
(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.

Updated

14 years ago
Attachment #166162 - Flags: review?(emaijala) → review+

Comment 11

14 years ago
(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?
(Assignee)

Comment 12

14 years ago
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.

Comment 13

14 years ago
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?
(Assignee)

Comment 14

14 years ago
(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.

Comment 15

14 years ago
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...
(Assignee)

Comment 16

14 years ago
(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?
(Assignee)

Comment 17

14 years ago
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
(Assignee)

Comment 18

14 years ago
I should add that the proposed fixed also solves the problem for ZoomText.

Comment 19

14 years ago
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.

Comment 20

14 years ago
Created attachment 167733 [details] [diff] [review]
Ignore WM_KEYUP VK_MENU

So, not only does this patch fix this bug, but it also fixes the 9x alt-tab
bug.

Comment 21

14 years ago
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.
(Assignee)

Comment 22

14 years ago
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+

Comment 23

14 years ago
This seems so simple, and right, that it almost hurts.  Nice!

Comment 24

14 years ago
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)
(Assignee)

Comment 25

14 years ago
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+
(Assignee)

Comment 26

14 years ago
The Windows 9x bugs sound like bug 97014, bug 94175 and bug 93877. Should we
close those?
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Updated

14 years ago
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

Updated

5 years ago
Depends on: 708936
You need to log in before you can comment on or make changes to this bug.