Simon Lucy Reporter
	Description • 24 years ago

It seems that the mapping of the key states Alt, Control is broken.  The easy
example is Control-Alt-f  for Fishcam
(http://bugzilla.mozilla.org/show_bug.cgi?id=25369
).  This though isn't the only combination that fails.  For example, I set
Control '/' to set the focus to the URLBar and rotated through all combinations
of Contrl,Alt,'/' and each failed to fire the oncommand handler.  I changed the
XUL to use VK_F12 and the function key sets the focus each time.  However, it
also sets the focus on Control+Alt+F12 as well.

This leads me to believe that there is a flaw in the low level mapping of
makecode modifiers.  I'll investigate more today.

	timeless
	Comment 1 • 24 years ago

yes i saw this a long time ago when i first worked on fishcam. but i couldn't 
reduce the problem usefully :-(

	Johnny Stenback (:jst)
	Comment 2 • 24 years ago

Over to the owner of DOM Events.

	joki (gone)
	Comment 3 • 24 years ago

This would be a problem at the lowest key event creation level.  I'm not sure 
who owns that these days.  I've had some portion of this ownership in the past 
but haven't done much with it in a while.  In any case, not high enough priority 
 for inclusion in milestone 0.9

	Stephan Niemz
	Comment 4 • 24 years ago

Adding more dependencies.

Please keep in mind the following comment from mpt in bug 67596:

Ctrl+Alt+anything should be avoided -- leave it for the OS (e.g. Ctrl+Alt+Delete) 
or window manager (e.g. Ctrl+Alt+I).

	Simon Lucy Reporter
	Comment 5 • 24 years ago

That's true inasmuch as regular implementations go (Ctrl-Alt-F aside), however
for some embedded implementations, true kiosk mode etc, Ctrl-Alt combinations
may need to be filtered out.

	Blake Ross
	Comment 6 • 23 years ago

-> Dan

This has something to do with our setting of mIsControlDown/mIsAltDown, like in 
http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsWindow.cpp#2952.  
I don't understand this -- it prevents ctrl and alt from firing at the same 
time in moz -- and though msdn mentions the context code referenced here, it's 
no help in explaining it.

	Blake Ross
	Comment 8 • 23 years ago

It looks like we have a cut and paste problem here (given the various 
inaccurate // WM_KEYUP's).

This fix sets things straight in accordance with 
http://msdn.microsoft.com/library/psdk/winui/keybacel_125u.htm (which says that 
the context code is set even during WM_SYSCHAR, so there's no point in special 
casing) and http://msdn.microsoft.com/library/psdk/winui/keybinpt_9l7y.htm 
(which says that the context code is always 0 during WM_KEYDOWN, so there's no 
point in double checking).

Note that though this patch fixes ctrl+alt events, key events like the fishcam 
still aren't working.  I still have to investigate further on that.

Dan, comments / review?

	Blake Ross
	Comment 10 • 23 years ago

Well, the last patch broke stuff.  Here's a new one.  Keep in mind that I have 
no idea why this works, because, according to 
http://msdn.microsoft.com/library/psdk/winui/keybinpt_9l7y.htm, the context 
code is always 0 on WM_KEYDOWN, so this should be equivalent to the current 
code.

	Dan M
	Comment 11 • 23 years ago

  A combination of reading Petzold and experimentation leads me to believe that 
the KF_ALTDOWN bit (the Context Code) is set on WM_KEYDOWN messages to alert you 
of a combination of modifier keys that's likely to be a special key on a non-US 
keyboard. I don't have such a keyboard, but apparently, despite the fact that the 
alt key is down, you want to treat it like a normal character. My US keyboard 
sets the KF_ALTDOWN bit if the alt key and some other modifier are both set.
  It looks like we have a conflict between correct treatment of special 
characters and catching the ctrl+alt key combination as a double-modified simple 
character. I don't know how we should treat these special characters, so I'm 
expanding the cc: list. Frank?

	timeless
	Comment 12 • 23 years ago

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

	Ben Bucksch (:BenB)
	Comment 13 • 23 years ago

Adding Ctrl-Alt-q for Quit as dep.

	Bernie McGuire
	Comment 14 • 23 years ago

I've been looking at this problem and have a fix that will allow us to see the 
Ctrl+Alt as well as fire keypress events for the keystrokes, but the fix is in 
the same source module (nsWindow.cpp) that I have another fix in for a 
different bug (50255) that is currently under review. 

Can someone tell me how I can post a patch here without including my fix for 
50255? Or should my patch for this bug include my fix for 50255 also? 

I'm new here so I'm not familiar with all the procedures yet. 

Please advise
Bernie McGuire

	Aaron Leventhal
	Comment 15 • 23 years ago

I know three ways of dealing with conflicting patches
1. Hand edit your patches
2. Work on different builds at the same time - use each for a diffrent bug
3. When you post your patch, just post it completely and see this also fixes bug
#blah

	Bernie McGuire
	Comment 16 • 23 years ago

Here is a possible patch

Patch Summary:
Purpose: Dispatch  ctrl+alt+keystrokes 
Changes:
1.	Remove setting of mIsShiftDown, mIsAltDown and mIsCtrlDown from the
WM_CHAR processing as these variables are always set during WM_KEYDOWN
processing and therefore it is redundant to do it during WM_CHAR processing. 
2.	The only time WM_SYSKEYDOWN message is generated is when the Alt key is
pressed. Therefore, setting of the mIsCtrlDown must be done on the WM_KEYDOWN
not WM_SYSKEYDOWN. Likewise on the WM_KEYUP message. As a matter of fact,
setting it on both the WM_KEYDOWN and/or WM_SYSKEYDOWN is part of the problem. 

3.	The status of the Alt key is available during either WM_KEYDOWN and
WM_SYSKEYDOWN so it is not necessary to test for msg=WM_SYSKEYDOWN to set the
value of mIsAltKeyDown. NOTE also that a WM_SYSKEYDOWN is NOT generated if the
operator pressed Ctrl BEFORE pressing ALT when using the two keys in
combination! So setting of mIsAltDown could be missed in that case.
4.	Generate a DispatchKeyEvent in OnKeyDown for the Ctrl+Alt combination
with keycode in the virtualkeycode (not keycode), because if DispatchKeyEvent
has the keycode set Window’s menu processing will be activated. 

Item 4 above needs testing by someone with the fishcam to see if passing in the
virtualkeycode to DispatchKeyEvent will  activate fiscam.

Note this patch contains NO other patches for nsWindow.cpp.

	Ere Maijala (slow)
	Comment 17 • 22 years ago

I applied the patch manually, but it doesn't work. It seems that passing the
virtual key doesn't work. As a sidenote, anyone can see the fishcam if
ctrl-alt-f works. 
I changed OnKeyDown to pass char code (changed to lowercase) instead of virtual
key. It fixes fishcam, but it looks like this patch breaks AltGr handling (right
alt on many European keyboards). I think AltGr is seen as Ctrl-Alt. For example
on a Finnish keyboard it is used to input characters such as @ (AltGr-2), $
(AltGr-4) and \ (AltGr-+).

	Joshua Prowse
	Comment 18 • 22 years ago

The OS is more than Win2000.  For example, I have this issue on WinXP

	Wladimir Palant
	Comment 19 • 21 years ago

Windows doesn't make a difference between Ctrl-Alt and AltGr (Ctrl-Alt-2 should
produce the same @ symbol on your keyboard). But AltGr handling is only
necessary for the WM_CHAR message. This means that keeping the lines 3331-3347
unpatched should fix the AltGr problem while not affecting anything else
including fishcam (which is triggered by the WM_KEYDOWN message I suppose).

	Ere Maijala (slow)
	Comment 20 • 21 years ago

If you mean having the special casing for WM_CHAR (the line numbers don't
match), I'm not sure that's the best way to do it. 

	Wladimir Palant
	Comment 21 • 21 years ago

I meant the line numbers from the last patch attached by Bernie McGuire. They
don't match the line numbers of the latest version of course.

I think the special handling for WM_CHAR is the way how it is done in Windows.
You just ignore the modifiers for this message, you use the character the
operating system gives you. Of course you could still set mIsAltDown/mIsCtrlDown
and ignore them elsewhere for the keypress event (this would be in the widgets
that have to handle keyboard input I suppose), Internet Explorer is probably
handling it this way. But I'm not sure if this can be done in a cross-plattform
program and anyway - it is much harder to implement.

	Wladimir Palant
	Comment 22 • 21 years ago

To make it clear - you won't get a WM_CHAR message at all if you press
Ctrl-Alt-F because it's a special key combination. You will only get WM_CHAR for
Ctrl-Alt-2 or AltGr-2 because this combination produces a plain character. And
you have to take this character as it is regardless of the modifiers.

	Wladimir Palant
	Comment 23 • 21 years ago

From
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/keyboardinput/keyboardinputreference/keyboardinputmessages/wm_char.asp:

"Because there is not necessarily a one-to-one correspondence between keys
pressed and character messages generated, the information in the high-order word
of the lParam parameter is generally not useful to applications. The information
in the high-order word applies only to the most recent WM_KEYDOWN message that
precedes the posting of the WM_CHAR message."

The high-order word of the lParam contains in particular the modifier information.

	Marc Durdin
	Comment 24 • 18 years ago

Firefox's current behaviour for WM_CHAR/WM_IMECHAR/WM_SYSCHAR/WM_UNICHAR on Windows is incorrect.  A character message is a character message, not a key message.  Firefox should make NO assumptions about how that character message was generated (it could be from the keyboard, via a macro application, via a keyboard remapping application such as Tavultesoft Keyman, via a speech recognition app or via a handwriting recognition tool).  Firefox MUST just use the character as given.

The WM_SYSCHAR message is a special (and nearly legacy) case that should be used to activate an accelerator or menu.  Again this message could be produced by a speech recognition or accessibility tool, not necessarily just by pressing Alt+letter.

Currently, text input in Firefox using Tavultesoft Keyman fails on keyboards that require Ctrl or Alt modifiers due to this bug.

	Marc Durdin
	Comment 25 • 18 years ago

This patch reworks OnChar into OnSysChar, OnChar and adds OnUniChar.  All WM_CHAR messages received are now treated as pure character messages.  WM_SYSCHAR messages are treated as Alt+character events.

OnUniChar adds support for WM_UNICHAR, allowing Unicode input on 9x with Tavultesoft Keyman.

	Marc Durdin
	Comment 26 • 18 years ago

Patch for WM_CHAR handling to resolve Ctrl, Alt modifiers

This patch reworks OnChar into OnSysChar, OnChar and adds OnUniChar.  All
WM_CHAR messages received are now treated as pure character messages. 
WM_SYSCHAR messages are treated as Alt+character events.

OnUniChar adds support for WM_UNICHAR, allowing Unicode input on 9x with
Tavultesoft Keyman.

Previous patch didn't handle Esc, Tab correctly in dialogs.  Now it does.

	Marc Durdin
	Comment 27 • 18 years ago

Suggest updating:

Component - Widget:Win32
Severity - Major
Target Milestone - 1.8.1
OS - WinXP

Previous patch is for TRUNK - would need revision for 1.8.1 branch

	Ere Maijala (slow)
	Comment 28 • 18 years ago

Comment on attachment 244854 [details] [diff] [review]
Patch for WM_CHAR handling to resolve Ctrl, Alt modifiers [fix Tab, Esc in dialogs from previous patch]

The patch doesn't apply to the trunk. There is also no need to add anything Windows 9x specific into trunk where old versions are not supported.

	Serge Stroobandt
	Comment 29 • 18 years ago

I suggest raising the priority of this bug.

This bug has rendered Firefox virtually useless to enter web forms, and this for at least an entire country!!!

Let me explain:
On a Belgian keyboard you need to hit "Alt Gr" + "2", to get the "@"-sign. (To fill out this email form, I actually had to cut and paste this character !!!)
So any time I want to enter my email address or an accented character in a form, Firefox opens menus and becomes unresponsive.

For any web transaction, I have to resort to *pera now...

	Christian :Biesinger (don't email me, ping me on IRC)
	Comment 30 • 18 years ago

Serge, that's unrelated to this bug... please file a new one about that.

	Mathew Hodson
	Comment 31 • 6 years ago

This should be resolved as a duplicate of bug 197474.

A fix was made in that bug, and these shortcuts started working again.

	Simon Lucy Reporter
	Comment 32 • 6 years ago

As the Reporter I don't mind this being closed if all Ctrl-Alt keys are useable, but I see that https://bugzilla.mozilla.org/show_bug.cgi?id=37594 is still open and was reopened 2 years ago.

This is an old irritation but it makes no sense that this remained at NEW and patches were produced for it.

	Mathew Hodson
	Comment 33 • 6 years ago

This is a duplicate of bug 197474, and it was fixed there many years ago. I am not aware of any shortcuts that don't work. For example, I can use Ctrl+Alt+P for presentation mode on PDF pages.

Bug 37594 is a request for a new debugging feature. This bug doesn't depend on whether that feature is implemented.