The Keyboard events in javascript just show the interaction between the user and the key of the keyboard, it does not indicate any contextual meaning of that interaction. The event types such as keydown, keypress, or keyup describe what sort of keyboard activity occurred.Īll the keyboard events in JavaScript that are triggered when a user presses a key belongs to the KeyboardEvent Object. The three main keyboard events in JavaScript are, keydown, keypress, and keyup. When a user presses any keyboard key, a keyboard event is triggered. 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.The interaction of the user with the keyboard, triggers various keyboard events. 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. 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). And having to set a pref to make a game work seems like only a 10% solution. 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. One idea would be to introduce a pref that controls whether keys are suppressed as bug 262894 does. 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). 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. Thus:įx event sequence w/o window-eyes *after* bug 262894: keydn alt, keydn enter, keyup enter (*** wrong)įx event sequence w/ window-eyes *after* bug 262894: keydn alt (*** wrong, but gives the desired behavior)īug 262894 also has a patch based on a different approach, which was not used. The undesired behavior was happening only on hotkeys, so the patch just suppresses all events of the form (keyup alt). ![]() 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). Win event seq w/ window-eyes: syskeydn alt, keyup altįx event sequence w/o window-eyes *before* bug 262894: keydn alt, keydn enter, keyup enter, keyup alt (*** correct)įx 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)īug 262894 got the desired behavior with a 1-line fix. Standard windows event seq: syskeydn alt, syskeydn enter, syskeyup enter, keyup alt Key sequence: press alt, press enter, release enter, release alt 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. An example is "Window-Eyes".Īlt-Enter is apparently a global hotkey for Window-Eyes. That bug was fixed in order to make screen reader software (and other accessibility) software that has global hotkeys work well with Firefox. ![]() I think that anything that starts with (press alt, press other) will go wrong. #2 also fails if you use a key other than a or if the releases happen in a different order. Windows event sequence: syskeydn alt, syskeydn a, syskeyup a, keyup altįirefox event sequence: keydn alt, keydn a, keyup aģ. Key sequence: press alt, press a, release a, release alt If you do the sequence (press alt, press a, release a, release alt), events DO NOT work correctly. Windows event sequence: syskeydn alt, syskeyup altįirefox event sequence: keydn alt, keyup altĢ. If you do the sequence (press alt, release alt), events work correctly. In short, pressing the Alt key by itself works fine, but pressing it with other keys (as in a hotkey) doesn't work. ![]() * What happens with the Alt key in Firefox on Windows I spent some time digging into the current state of things, so I think I can give you a good summary: Apparently it's messing up common game control schemes that use the Alt keys. Martin, Vlad: lemeslep emailed me about this bug directly.
0 Comments
Leave a Reply. |