Closed Bug 431468 Opened 16 years ago Closed 16 years ago

Using right alt key in keyboard shortcuts has no effect

Categories

(Core :: Widget: Win32, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: Jamie, Assigned: masayuki)

Details

(Keywords: access, regression)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042906 Minefield/3.0pre

Many keyboard shortcuts include the alt key; e.g. accessing menus, shortcut keys such as alt+d to move to the address bar, access keys on web pages, keyboard shortcuts in dialogs, etc. Currently, these work correctly when the left alt key is used. However, if the right alt key is used with these shortcuts, they have no effect. Note that pressing the right alt key alone to focus the menu bar works correctly.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox.
2. Ensure that the address bar is not focused.
3. From the main window, press left alt+d to access the address bar. Observe that this works correctly.
4. Press left alt+f to activate the File menu and then alt to exit. Observe that this works correctly.
5. Press the right alt key to activate the menu bar and then again to deactivate it. Observe that this works correctly.
6. Move focus away from the address bar.
7. Press right alt+d to activate the address bar. Observe that this has no effect.
8. Press right alt+f to activate the File menu. Observe that this has no effect.
Actual Results:  
Using the right alt key for shortcut keys as in steps 7 and 8 has no effect.

Expected Results:  
Using the right alt key for shortcut keys as in steps 7 and 8 should perform the desired function as in steps 3 and 4.
Keywords: access
Version: unspecified → Trunk
mmmm... This may be a regression from Fx2.

http://mxr.mozilla.org/mozilla/source/widget/src/windows/nsKeyboardLayout.cpp#449
448 #ifndef WINCE
449 PRUint8 KeyboardLayout::GetShiftState (const PBYTE aKbdState)
450 {
451   PRBool isShift = (aKbdState [VK_SHIFT] & 0x80) != 0;
452   PRBool isCtrl  = (aKbdState [VK_CONTROL] & 0x80) || (aKbdState [VK_RMENU] & 0x80);  // Right Alt (AltGr) = Alt + Ctrl
453   PRBool isAlt   = (aKbdState [VK_MENU] & 0x80) != 0;
454   PRBool isCaps  = (aKbdState [VK_CAPITAL] & 0x01) != 0;
455 
456   return ((isCaps << 3) | (isAlt << 2) | (isCtrl << 1) | isShift);
457 }

isAlt should be true if (VK_RMENT & 0x80) && (that is not AltGr).
Status: UNCONFIRMED → NEW
Component: Keyboard: Navigation → Widget: Win32
Ever confirmed: true
Flags: blocking1.9?
Keywords: regression
QA Contact: keyboard.navigation → win32
Oh, I misunderstood.

When right alt key is pressed, VK_RMENU is true. Therefore, only right alt pressing makes isCtrl = true && isAlt = true.
Attached patch Patch v1.0Splinter Review
I think this is correct.

If right alt key is AltGr, that should be Ctrl+Alt in the native state. So, we don't need to check VK_RMENU. This patch works fine on Vista for me. But I'm not sure this is correct on all keyboard layouts and on WinXP and Win2k.

Why is there such code??
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #318613 - Flags: review?(emaijala)
Comment on attachment 318613 [details] [diff] [review]
Patch v1.0

Indeed that seems to be a blunder from bug 287179 and of course only evident on layouts that don't use AltGr.
Attachment #318613 - Flags: review?(emaijala) → review+
Attachment #318613 - Flags: superreview?(roc)
Attachment #318613 - Flags: superreview?(roc) → superreview+
Attachment #318613 - Flags: approval1.9?
Comment on attachment 318613 [details] [diff] [review]
Patch v1.0

a1.9+=damons
Attachment #318613 - Flags: approval1.9? → approval1.9+
checked-in.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Flags: blocking1.9?
Resolution: --- → FIXED
Verified fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050506 Minefield/3.0pre.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: