Closed Bug 9333 Opened 27 years ago Closed 25 years ago

[key] Win32 - AltGR key activates menu

Categories

(Core :: Internationalization, defect, P3)

Product:
Core
Component:
Internationalization
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: momoi, Assigned: rods)

References

Details

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

(This bug imported from BugSplat, Netscape's internal bugsystem.  It
was known there as bug #87307
http://scopus.netscape.com/bugsplat/show_bug.cgi?id=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
installed.

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
windows.

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?
Reasigning to Charley Manske, who is in charge of the WinFE.
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.
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
Bugzilla.

------- 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.
Assignee: cmanske → tague
Status: REOPENED → NEW
QA Contact: teruko
tague, how are we doing with this kind of key combination under 5.0?
Status: NEW → ASSIGNED
Target Milestone: M15
taken under advisement
Depends on: 13016
*** Bug 13036 has been marked as a duplicate of this bug. ***
Blocks: 15693
Assignee: tague → ftang
Status: ASSIGNED → NEW
reassign to ftang per i18ngrp reassignment meeting.
Target Milestone: M15 → M11
Status: NEW → ASSIGNED
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"
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
fix in keyEvent_19991004_BRANCH landing
Summary: [key](Right)-ALT s hides the Composer's status bar rather than input special accented "S" → [key] AltGR activates menu
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I tested this in 10-29-08 Win32 build.  This does not work, so I reopen this.
Assignee: ftang → saari
Status: REOPENED → NEW
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 ?
Status: NEW → ASSIGNED
Target Milestone: M11 → M12
M12
Target Milestone: M12 → M13
Target Milestone: M13 → M15
Adding [PDT+] based on comments made in bug 13016, which was erroneously
reopened.
Summary: [key] AltGR activates menu → [PDT+][key] AltGR activates menu
Summary: [PDT+][key] AltGR activates menu → [PP][key] Win32 - AltGR key activates menu
Whiteboard: [PDT+] No estimated fix.
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.
*** Bug 24349 has been marked as a duplicate of this bug. ***
*** Bug 24781 has been marked as a duplicate of this bug. ***
Keywords: pp
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.
Thanks,
Jim
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?
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 
information.

Do you mean "physically" on the keyboard or from a coding point
of view? If the latter, Frank Tang should address the question.
The latter.  In Win32-speak, how are the keys distinguished?  We're obviously 
treating them as the same key right now.

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. 
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).

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.

This is needed for Beta1 for European users based on comments here and
a number of discussion groups we are monitoring.
Keywords: beta1
Priority: P1 → P3
Target Milestone: M15 → M14
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
   Turkish.


*** Bug 26205 has been marked as a duplicate of this bug. ***
*** Bug 26412 has been marked as a duplicate of this bug. ***
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.

*** Bug 26701 has been marked as a duplicate of this bug. ***
Summary: [PP][key] Win32 - AltGR key activates menu → [key] Win32 - AltGR key activates menu
Will the isAlt bit have the same problem at the widget level?

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?

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...
*** Bug 26721 has been marked as a duplicate of this bug. ***
*** Bug 13016 has been marked as a duplicate of this bug. ***
Blocks: 26981
I'm probably not the best person to fix this...
Keywords: helpwanted
http://www.microsoft.com/GLOBALDEV/europe/Altgmsdn.asp
I think, this should help to solve the problem.

You are my hero.  I'll take a look at this.
Assignee: saari → hyatt
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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
Status: ASSIGNED → NEW
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.

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 
27463
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Keywords: helpwanted, pp
Resolution: --- → FIXED
I verified this in 2000021408 Win32 build under Winnt 4.0 and Win95.
Status: RESOLVED → VERIFIED
*** Bug 30443 has been marked as a duplicate of this bug. ***
*** Bug 28939 has been marked as a duplicate of this bug. ***
*** Bug 31497 has been marked as a duplicate of this bug. ***
*** 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.