[key] Win32 - AltGR key activates menu




21 years ago
19 years ago


(Reporter: momoi, Assigned: rods)


Windows 95
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+] No estimated fix.)



21 years ago
(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #87307
Imported into Bugzilla on 07/06/99 22:44)

** Observed with 4.03 Windows build **

This bug report comes from a Polish user who uses Communicator to compose
in Polish. The usual way in which to input the sharp-accented "s" is by
the use of "Right-ALT s" or "Right-ALT S" -- with the Polish keyboard file

This works fine for NT, but for Windows 95, it hides or unhides the status
bar at the bottom of a Communicator window instead.

By the way, Left-ALT s normally hides or unhides the Windows Task Bar if the
mouse cursor is outside a Communicator window. (You need to have chosen the
"Do not automaticaly hide teh Task Bar option first).

This is a problem for those dependent on this key stroke to input their
accented S.  Most probably affects some ISO-8859-2 languages.

To reproduce this:

1. Use Window 95 (US or other versions)
2. Install the Pollish keyboard option
3. Open a new/blank composer page
4. Switch the encoding setting to ISO-8859-2
5. Put the cursor in the composer window, and
6. Press Right-ALT s or Right-ALT S and see the bottom status disappear and
   appear again.
   This also happens on our browser window, too.

In comparison, this does not happen with IE3 and some other Communicator

This does not happen on NT4. When you take Step 6 above on an NT, you will
see the sharp-acecented "s" or "S".

Is this something we can fix by fiddling with pref.js?

Comment 1

21 years ago
Reasigning to Charley Manske, who is in charge of the WinFE.

Comment 2

21 years ago
Probably a keyboard driver bug? We have an Alt Ctrl S accelerator that shows
and hides the status bar. In the "AltGr" keyboard mode (pressing right Alt   a
key when in a foreign language), this function is triggered by just the right
Alt S, as stated above. Looking at the keyboard pages, this is a potential
problem in Czeck, Latvian, Hungarian, and Slovak. Also, inn Canadian, Dutch and
Turkish, the Alt S is supposed to enter the greek capital Beta key.
The solution is to remove the accelerator and detect Alt S in the OnChar
message handler.

Comment 3

20 years ago
We must support all possible international keyboards!

------- Additional Comments From paulmac  Jul-06-1999 20:03 -------

This bug is marked TFV 5.0 but does not appear relevant in Seamonkey's new code
base, so marking Resolved WONTFIX. If it's still relevant, please re-open bug in

------- Additional Comments From momoi  Jul-06-1999 22:47 -------

Actually, I'm going to move this bug over to 5.0 as a reminder
bug to make sure we'll take care of it right.


19 years ago
Assignee: cmanske → tague
QA Contact: teruko

Comment 4

19 years ago
tague, how are we doing with this kind of key combination under 5.0?


19 years ago
Target Milestone: M15

Comment 5

19 years ago
taken under advisement


19 years ago
Depends on: 13016

Comment 6

19 years ago
*** Bug 13036 has been marked as a duplicate of this bug. ***


19 years ago
Blocks: 15693


19 years ago
Assignee: tague → ftang

Comment 7

19 years ago
reassign to ftang per i18ngrp reassignment meeting.


19 years ago
Target Milestone: M15 → M11


19 years ago
Priority: P3 → P1
Summary: (Right)-ALT s hides the Composer's status bar rather than input special accented "S" → [key](Right)-ALT s hides the Composer's status bar rather than input special accented "S"


19 years ago
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 8

19 years ago
fix in keyEvent_19991004_BRANCH landing


19 years ago
Summary: [key](Right)-ALT s hides the Composer's status bar rather than input special accented "S" → [key] AltGR activates menu

Comment 9

19 years ago
Changing Summary to make for easier regression. As this bug was originally
written, it referred to a feature that is not present in 5.0 browsers, but only
4.x browsers.

In 5.x browsers, pressing the AltGR key activates the menu. This is incorrect
behavior; it should do nothing. In the 1999101411 builds, pressing AltGR+S (for
example) types both a 'ß' *and* activates the Search menu.

[In 4.0x browsers, pressing the AltGR key behaves the same as Ctrl+Alt+S. This
is covered in bugsplat, the internal Netscape bug database.]

This is not fixed in the 1999101411 build on either Windows 98 or Windows NT.
Which build should this be fixed in?


19 years ago


19 years ago
Resolution: FIXED → ---

Comment 10

19 years ago
I tested this in 10-29-08 Win32 build.  This does not work, so I reopen this.


19 years ago
Assignee: ftang → saari

Comment 11

19 years ago
I am sure that I didn't set the isAlt == PR_TRUE for those characters in
KeyPressed event. Somehow this still happen. Reassign to saari. saari- if you
have a window build, try the following.
1. Install a Polish keyboard in WinNT/95 by going to the keyboard control panel.
2. Switch to Polish keyboard by clicking the right lower corner keyboard menu
which appeared after you install the Polish keyboard
3. in composer, hit Right Alt + 'e'. You will notice a correct 'e' hook insert
into editor. But somehow it ALSO bring down the Edit menu.

If you have a window build, go to mozilla/widget/src/windows/nsWindow.cpp and
uncommet the // #defined KE_DEBUG line
cd mozill/widget
nmake -f makefile.win
Then try again, you will find out that the isAlt is not set when you hit the
rigth Alt+'e' (which is CORRECT)

8 DispatchKE Type: PRESS charCode 281  keyCode 0 Shift: U Control U Alt: U

Please take a look at the keybinding code to see why it still bring down the
Edit menu.
Are you looking at KeyDown or KeyUp somewhere instead of KeyPress ?


19 years ago
Target Milestone: M11 → M12

Comment 12

19 years ago


19 years ago
Target Milestone: M12 → M13


19 years ago
Target Milestone: M13 → M15

Comment 13

19 years ago
Adding [PDT+] based on comments made in bug 13016, which was erroneously
Summary: [key] AltGR activates menu → [PDT+][key] AltGR activates menu


19 years ago
Summary: [PDT+][key] AltGR activates menu → [PP][key] Win32 - AltGR key activates menu
Whiteboard: [PDT+] No estimated fix.

Comment 14

19 years ago
Bug 17683, "[Dogfood] ALTGr + NUM Pad key operation shifts focus to menu",
has been fixed for two months now... the fix for that may or may not be
informative for fixing this bug - this may have been fixed only for ALT,
not ALTGr.

Comment 15

19 years ago
*** Bug 24349 has been marked as a duplicate of this bug. ***

Comment 16

19 years ago
*** Bug 24781 has been marked as a duplicate of this bug. ***


19 years ago
Keywords: pp

Comment 17

19 years ago
I was a little confused about how this got a PDT+, but never even got a 
nomination as bein dogfood.  This mixed status confuses our queries etc.
IF you want to nominate it for dogfood, add that to the summary... but it 
doesn't make sense to have PDT+ without a nomination and review by the PDT.

Comment 18

19 years ago
I would like to think that this is a beta 1 material for 
many ISO-8859-2 users whose keyboard would involve
AltGr+V to input "@". Any opinions?

Comment 19

19 years ago
I need someone to tell me how to distinguish Alt from AltGr.  This bug cannot be 
fixed until I know how to do this.  I'm not going to spontaneously acquire this 

Comment 20

19 years ago
Do you mean "physically" on the keyboard or from a coding point
of view? If the latter, Frank Tang should address the question.

Comment 21

19 years ago
The latter.  In Win32-speak, how are the keys distinguished?  We're obviously 
treating them as the same key right now.

Comment 22

19 years ago
hyatt- When do you need to distinguish between them ? KeyUp, KeyDown, 
or KeyPressed ? 

For US keyboard, both the Alt and AltGR are only used for non character input, 
so you got the same message. For the keyboard layout which use AltGR to input 
character (for example- polish), I clean up IsAlt in the KeyPressed. Howerver, I 
am not sure I send the same or different KeyUp and KeyDown event. 

Can you tell me where is  your code which track the Alt ? (file, function name). 
Then I can help to look at it. 

Comment 23

19 years ago
I don't think it's my code that is the problem.  I think it's in the 
Windows widget code... when an AltGr is pressed, someone needs to make sure that 
an ALT key press event is not sent into the DOM... or that, if it is, the key 
event is somehow distinguishable (charcode, keycode, whatever).

Comment 24

19 years ago
Please rethink the target milestone. Because of this Bug your not able to type
any eMail adress with central-europe keyboard layout. So you can't really use
the browser.

Comment 25

19 years ago
This is needed for Beta1 for European users based on comments here and
a number of discussion groups we are monitoring.
Keywords: beta1


19 years ago
Priority: P1 → P3
Target Milestone: M15 → M14

Comment 26

19 years ago
The current problem status is as follows:

1. When AltGr+V is engaged in Browser or Composer, instead of "@" in all Central European languages,
   we get the View menu open instead.
2. When AltGR+Q is engaged in Browser, the QA menu opens instead of inputting "@" in German, Icelandic and

Comment 27

19 years ago
*** Bug 26205 has been marked as a duplicate of this bug. ***

Comment 28

19 years ago
*** Bug 26412 has been marked as a duplicate of this bug. ***

Comment 29

19 years ago
Window currenlty do not send KeyPress for ALT at all, it only send KeyDown and
KeyUp for ALT. Instead of tracking of  ALT key, you should check the isAlt bit
in the non ALT keyPress instead.

Comment 30

19 years ago
*** Bug 26701 has been marked as a duplicate of this bug. ***


19 years ago
Summary: [PP][key] Win32 - AltGR key activates menu → [key] Win32 - AltGR key activates menu

Comment 31

19 years ago
Will the isAlt bit have the same problem at the widget level?

Comment 32

19 years ago
I find it amusing that out of all the people CC'ed on this bug, none of us seem 
to have the expertise to know how to distinguish ALT from ALTGr on Win32.  Is 
there nobody out there who knows how to tell when AltGr is pressed, so that we 
can treat it differently from Alt?

Comment 33

19 years ago
If you have a look at the scancodetable of the keys you can see that [Alt] has 
Scancode 60, while [AltGr] has 62. (http://www.barcodeman.com/scan_doc.html)

Isn't it possible to read that data out? Sorry my C knowledge is a little bit 
rusty, will investigate a little bit further...

Comment 34

19 years ago
*** Bug 26721 has been marked as a duplicate of this bug. ***

Comment 35

19 years ago
*** Bug 13016 has been marked as a duplicate of this bug. ***


19 years ago
Blocks: 26981

Comment 36

19 years ago
I'm probably not the best person to fix this...
Keywords: helpwanted

Comment 37

19 years ago
I think, this should help to solve the problem.

Comment 38

19 years ago
You are my hero.  I'll take a look at this.
Assignee: saari → hyatt


19 years ago

Comment 39

19 years ago
I am now reassigning this bug to rods, since it's now down to a bug in the Win32 
widget code.

rod, AltGR is equivalent to CTRL+ALT, and in fact, on US keyboards CTRL+ALT
won't activate the menu.  ALT by itself will, but CTRL+ALT will not.

I have modified my DOM listener so that it checks to see if the CTRL key is 
down when it gets the ALT keydown message.  If so, then it won't activate.  
Unfortunately, I'm running into a bug in the windows widget code.  The generated 
key down event is claiming that the CTRL key is not down, when in fact it is.  

Relevant function is nsWindow::DispatchKeyEvent.
Assignee: hyatt → rods

Comment 40

19 years ago
You can easily test this by hitting CTRL+ALT in Mozilla.  Right now, it will 
cause the "File" menu to highlight.  If you get everything working, then ALT by 
itself will highlight the File menu, but CTRL+ALT will not.

Comment 41

19 years ago
The issue is that the Windows dispatches an event with the VK_ALT in the KeyCode 
and the ALT flag set to false. It seems to me that we should be clearing the Key 
Code if it is VK_ALT and the ALT flag is false.

I fixed the XULMenuBarListener code to check both the KeyCode and the flag and 
it now works. 

Opening new bug to further track what we should do with the non-PDT+ issue. Bug 
Last Resolved: 19 years ago19 years ago
Keywords: helpwanted, pp
Resolution: --- → FIXED

Comment 42

19 years ago
I verified this in 2000021408 Win32 build under Winnt 4.0 and Win95.

Comment 43

19 years ago
*** Bug 30443 has been marked as a duplicate of this bug. ***
*** Bug 28939 has been marked as a duplicate of this bug. ***

Comment 45

19 years ago
*** Bug 31497 has been marked as a duplicate of this bug. ***

Comment 46

19 years ago
*** Bug 32504 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.