Re: Issue Request for DOM L3 Events

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