Re: Proposal to add USB keycodes to the current DOM3 key events

On Thu, Sep 13, 2012 at 12:15 AM, Masayuki Nakano <masayuki@d-toybox.com>wrote:

> Hi, I'm a developer of Gecko. So, I'd like to comments to this document.


Thanks for your comments and my apologies for taking so long to respond.


> On 2012/09/08 3:37, Gary Kacmarcik (Кошмарчик) wrote:
>
>> Problems with the current DOM Level 3 key events
>> ==============================**==================
>>
>> Problem 1: Matching keydown and keyup events
>> ------------------------------**--------------
>>
>> The main problem with the current proposal is that it doesn't provide
>> enough information so that keyup events can be matched with their
>> corresponding keydown event. In this regard, it is unlike the legacy
>> events, where the keyCode value was usually sufficient to match the
>> keydown/keyup events.
>>
>
> Yeah, but there are some cases that only keydown or only keyup event is
> fired.
>
> * If focus is moved to another window or something while some keys are
> pressed, keyup event are never fired if the keys are released while the
> browser is deactive.
> * If the browser becomes active while some keys are pressed, only keyup
> events are fired if the keys are released while the browser is active.
>

These are both true and valid. However, they describe a separate issue from
what we're trying to solve here.

Even in the best case scenario where you have not lost any key events, we
can not reliably match them with the current specification.
Even if we solve the problem of how to handle "lost" keyups/keydowns when a
window loses/gains focus, we still can not reliably match them with the
current specification.

* If a utility software or IME generates fake native key event to the
> browser, it may cause only keydown or keyup event if the native key event
> isn't one or more sets of native keydown and keyup events.
>

While I don't fully understand the intricacies of how events are fired from
IMEs, I don't believe that we're any worse off in this case.  But we're not
trying to solve the "missing key event" problem, we're trying to solve the
problem where both the keydown and the keyup are present but cannot be
matched because the |key| value is different for the keydown and keyup
event.

So, anyway, it's very difficult issue to know if a key is actually pressed.


Yes. But even if you haven't lost any events, the current spec does not
allow events to be reliably matched.

 For examples of why this is a problem, consider the following scenarios:
>>
>> * Games and other applications which treat the keyboard as a large
>> collection of buttons need to be able to keep track of which keys are
>> currently being held down. Since there is no API to query the current
>> keyboard state, it is crucial that apps be able to match every keyup
>> event with the originating keydown event.
>>
>
> Only Windows (Win32, I'm not sure for Metro) has such native API. So, even
> if web specs defines such API, browsers cannot implement it on some
> platforms, unfortunately.


The lack of a nice cross-platform way of getting keyboard state means that
webapp developers will be relying on manual tracking of key up/down events.
I believe that makes it more important to make is possible to reliably
match a keyup event with its originating keydown event (again, assuming it
hasn't been lost or sent to another element).

 * Applications that provide remote access functionality often need to
>> keep track of the sequence of events that generated a particular
>> character. This is so that they can handle the case where the local
>> and remote systems have different keyboard layouts (since they may
>> require a different sequence of keys or modifiers to be injected on
>> the remote machine).
>>
>
> I don't understand this case. I think that applications should prefer the
> actual key event's information rather than the different keyboard layout...


Remote access systems need to match keydown and keyup events so that they
can (if necessary) inject appropriate modifier keys on the remote computer
so the correct key event is generated. A simple case would be a user at a
client machine (with a French keyboard) connecting to a remote host (with a
US keyboard). To type a '2', the user needs to hold the shift key on the
French keyboard. To properly generate this using low-level events on the
host (with the US layout), the shift key would need to be unpressed before
the '2' key event is injected.

This example is a bit esoteric, but basically remote access apps need to
track the keyboard state by matching keydown and keyup events.

 Proposal
>> ========
>>
>
>  A more complete mapping table between USB usage codes and
>> platform-specific scancodes can be found in the Chromium source code
>> at:
>> http://code.google.com/**searchframe#OAMlx_jo-ck/src/**
>> ui/base/keycodes/usb_keycode_**map.h<http://code.google.com/searchframe#OAMlx_jo-ck/src/ui/base/keycodes/usb_keycode_map.h>
>>
>
> That's interesting. But how should it behave with software keyboard on
> mobile device?


The USB spec has defined codes for a wide range of devices. For most mobile
devices, they would simply use the Keyboard/Keypad IDs (USB Usage Page
0x07).  Frankly, any values would work as long as they were the unique for
each key and the remained the same for keydown and keyup events. The
serious problem with the current spec is that the |key| and |char| values
can change between the keydown and keyup.

Thanks!
-Gary