Emil Hesslow Reporter
	Description • 18 years ago

I have a problem with the Alt-key and the KeyUp event. The thing I want to do is to press down Alt push a numeric value by pressing several keys and then release Alt. When Alt is released I want to know which number that was pressed.

So I've added listeners for keydown, keypress and keyup. I catch when the Alt is pressed down. Then I save all keys pressed. And then is my plan when the keyup is triggered for Alt I print the number that I saved. But there is no event triggered when the Alt-button is released.

This works on Linux but not on Windows and from what I can understand the problem is the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=262894 . Which means that the KeyUp event for the Alt-button isn't always fired.

	Mats Palmgren (inactive)
	Comment 2 • 18 years ago

I don't see how this can be fixed without regressing bug 262894.

	Emil Hesslow Reporter
	Comment 3 • 18 years ago

How do other program solves this or don't they allow you to do the thing I want?

	phi2x
	Comment 5 • 12 years ago

Oh, so this bug is known since 2006 :(

Seriously, if you want Firefox to welcome HTML5 games, this needs to be fixed.
Being able to use the Alt key as a fire button is a common scenario there.

	Mohit Bagra
	Comment 6 • 12 years ago

Any fix yet???

	David Mandelin [:dmandelin]
	Comment 7 • 12 years ago

Martin, Vlad: lemeslep emailed me about this bug directly. Apparently it's messing up common game control schemes that use the Alt keys. I spent some time digging into the current state of things, so I think I can give you a good summary:

* What happens with the Alt key in Firefox on Windows

In short, pressing the Alt key by itself works fine, but pressing it with other keys (as in a hotkey) doesn't work. In exact detail:

1. If you do the sequence (press alt, release alt), events work correctly. That is:

 key sequence: press alt, release alt
 windows event sequence: syskeydn alt, syskeyup alt
 firefox event sequence: keydn alt, keyup alt

2. If you do the sequence (press alt, press a, release a, release alt), events DO NOT work correctly. The keyup alt is missed:

 key sequence: press alt, press a, release a, release alt
 windows event sequence: syskeydn alt, syskeydn a, syskeyup a, keyup alt
 firefox event sequence: keydn alt, keydn a, keyup a

3. #2 also fails if you use a key other than a or if the releases happen in a different order. I think that anything that starts with (press alt, press other) will go wrong.

* Why Alt events are broken

This is a regression from bug 262894. That bug was fixed in order to make screen reader software (and other accessibility) software that has global hotkeys work well with Firefox. An example is "Window-Eyes".

Alt-Enter is apparently a global hotkey for Window-Eyes. Somehow, in the way that Window-Eyes gets this key sequence, it suppresses the key events for Enter, so Firefox doesn't see them, but Firefox still does see the Alt events. So:

 key sequence: press alt, press enter, release enter, release alt
 standard windows event seq: syskeydn alt, syskeydn enter, syskeyup enter, keyup alt
 win event seq w/ window-eyes: syskeydn alt, keyup alt
 fx event sequence w/o window-eyes *before* bug 262894: keydn alt, keydn enter, keyup enter, keyup alt (*** correct)
 fx event sequence w/ window-eyes *before* bug 262894: keydn alt, keyup alt (*** "correct", but this causes the menu bar to show, which isn't desired)

Bug 262894 got the desired behavior with a 1-line fix. The patch author realized that if the user presses Alt only, the the final event is (syskeyup alt), but if a hotkey, the final event is (keyup alt). The undesired behavior was happening only on hotkeys, so the patch just suppresses all events of the form (keyup alt) [as opposed to (syskeyup alt)]. Thus:

 fx event sequence w/o window-eyes *after* bug 262894: keydn alt, keydn enter, keyup enter (*** wrong)
 fx event sequence w/ window-eyes *after* bug 262894: keydn alt (*** wrong, but gives the desired behavior)

* Possible ways ahead

Bug 262894 also has a patch based on a different approach, which was not used. I didn't go through all the details, but it records one bit of history about keypresses and uses that to try to decide which keys to suppress. I think it would be better to find another way, though: the approach seemed complicated and it's hard to be sure it wouldn't have other problems (and I'm not even sure it avoids this issue).

One idea would be to introduce a pref that controls whether keys are suppressed as bug 262894 does. It seems hard to make this good, though: only one configuration could be the default, which I think would pretty much have to be the one where "accessibility software works", which means games don't work right by default. And having to set a pref to make a game work seems like only a 10% solution.

The idea I like most so far is to make the decision about whether to propagate a (keyup alt) to the DOM separately from the decision to show the menu (that was the actual undesired behavior--not the (keyup alt) per se). I don't actually what mechanism causes the menu to show in Firefox (is it DefWindowProc, or some Firefox-specific code) so I'm not sure the best way to do it. Bug 262894 comment 21 seems to be suggesting doing this by propagating an extra flag to the "menu bar listener" to tell it whether to show the menu.

	Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)
	Comment 8 • 12 years ago

Ew! Thanks for looking into this -- gives us a clear path forward.  We definitely need to fix this, and ideally need to figure out a way to test it going forward as well.  (Maybe some combination of firefox + AutoIt for sending key events?)

	neil@parkwaycc.co.uk
	Comment 9 • 12 years ago

The key handling code has changed in the last seven or so years since I wrote attachment 167733 [details] [diff] [review]. In particular I think we can now generate a "do not handle" key up event from widget code which the menu code will ignore.

	David Mandelin [:dmandelin]
	Comment 10 • 12 years ago

(In reply to neil@parkwaycc.co.uk from comment #9)
> The key handling code has changed in the last seven or so years since I
> wrote attachment 167733 [details] [diff] [review]. In particular I think we
> can now generate a "do not handle" key up event from widget code which the
> menu code will ignore.

Ah. That was one of your original proposals, wasn't it?

	neil@parkwaycc.co.uk
	Comment 11 • 12 years ago

(In reply to David Mandelin from comment #10)
> (In reply to comment #9)
> > The key handling code has changed in the last seven or so years since I
> > wrote attachment 167733 [details] [diff] [review]. In particular I think we
> > can now generate a "do not handle" key up event from widget code which the
> > menu code will ignore.
> 
> Ah. That was one of your original proposals, wasn't it?

No, I don't think it was, at least, not in bug 262894. In fact it turns out that my current suggestion was only very recently made possible by bug 749563!

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 13 • 11 years ago

Will be fixed by bug 708936.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900) Assignee
	Comment 14 • 11 years ago

fixed by bug 708936.

	Girish Sharma [:Optimizer]
	Comment 15 • 11 years ago

I think this should be reopened as the keyup event is having event.altKey as false.