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

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

taken under advisement

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

reassign to ftang per i18ngrp reassignment meeting.

fix in keyEvent_19991004_BRANCH landing

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?

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

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 ?

M12

Adding [PDT+] based on comments made in bug 13016, which was erroneously reopened.

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

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.

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

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

I'm probably not the best person to fix this...

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.

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.

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

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

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