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

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

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.

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

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

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

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

> Problem 2: Identifying keys by their position
> ---------------------------------------------
>
> While not as critical as the first problem, another common task for
> some applications (typically games) is to handle key events based on
> the key's position on the keyboard. For example, a game may want to
> detect when the key next to the CapsLock key is pressed so it can be
> associated with some player action. With a US keyboard, this would be
> the key with the 'A' keycap, but on an AZERTY keyboard, this key would
> have a 'Q' keycap.
>
> A layout-independent way of identifying keys would be useful to games,
> music/beatbox players, and other apps that prefer to consider the
> keyboard as a set of buttons. A touch-typing app could also use
> information to this target lessons for the home row or for the
> left/right hand.
>
> (Note that some implementations of HTML4 key events suffer from this
> problem as well. For example, the keycodes in WebKit-based browsers
> are based on Windows VKEY values, which are layout-dependent.)

I don't agree with this idea. I think that if games want to use 
different keys on different keyboard layouts as same key, games should 
provide the key configuration UI with some presets for major keyboard 
layouts.

But I do *not* object to following suggestion since there might be 
useful cases which I've never realized.

> 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

That's interesting. But how should it behave with software keyboard on 
mobile device?

-- 
Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.

Received on Thursday, 13 September 2012 07:15:45 UTC