Hmm, i stand corrected, somehow i wasn't triggering 3/4, the S3/Win
behaviour for
ALT down, ALT up, ALT down, ALT up
is
KeyDown, KeyUp, KeyUp
Which appears to be due to ALT activating the menu *sigh*
--Oliver
On Feb 27, 2008, at 1:39 PM, Oliver Hunt wrote:
I think it's probably worth pointing out that the special handling
of ALT is specific to Windows as ALT is used to activate menus, this
does not effect MacOS, and may or may not effect the various linux
browsers (i honestly have no idea what they do and don't have a
linux system to test on).
That said my (brief) testing of Safari for Windows shows that Safari
correctly pair ALT up/down in all of the scenarios below. The
testcase I used is at http://nerget.com/tests/input-testcase.html
--Oliver
On Feb 21, 2008, at 1:09 PM, Travis Leithead wrote:
I’d like to propose a discussion about the handling of the ALT +
key combination that will hopefully end in a normative requirement.
In observing IE as well as other browsers, there is “good” x-
browser consistency between the handling of ALT and pressing a
modifier key.
While the browsers are mostly consistent, they do so in a way that
is not very reliable for web developers because key down/key up
pairs are often not respected (key events get dropped in some
scenarios).
I’ve identified the following scenarios that we can discuss:
Scenarios for ALT handling where the key combination is not a
‘browser-reserved’ key:
(Using ‘X’ which is a non-reserved accelerator key—at least in IE/
Firefox3.)
1. Scenario 1: down ALT, down x, up ALT, up x
2. Scenario 2: down ALT, down x, up x, up ALT
3. Scenario 4: down ALT, up ALT, down ALT, down x, up ALT, up x
4. Scenario 5: down ALT, up ALT, down ALT, down x, up x, up ALT
In each of these scenarios, an ALT key up or down event is lost,
resulting in an inconsistent pairing of down/up events for the web
developer.
When handing scenarios for “browser-reserved” accelerator keys,
more key events are lost (including the simple ALT down/up pair
repeated twice). It would be nice to specify (perhaps in an
appendix) the behavior of browser-reserved accelerator key
combinations and what should be expected.
To help push the discussion along, I would like to propose two
potential ideas (one is more drastic than the other):
1. Create a requirement that browsers emit proper ALT key
sequences (up/down pairs) to the web page unless focus has shifted
out of the web page itself—here we would need to try to define
where to draw the line of when ALT is in focus and when it is not
in focus related to browser-reserved accelerator actions.
2. Remove the emission of modifier key (e.g., Shift/Alt/etc.)
events from the key identifiers set. Thus, pressing ALT (for
example) would not emit any keyboard events until a corresponding
key was pressed. The KeyboardEvent interface will continue to
support the Boolean modifier key flags so that distinctions between
a key + a modifier can be made by the web developer, but this will
cut back and the number of events raised and eliminate the out-of-
order key event problems (ALT down > key down > ALT up > Key up
versus ALT down > key down > key up > ALT up). Of course, a side
effect is that this outcome will also effectively remove the
detection of single modifier key presses for use in web applications.
