What should the keyCode be for key events generated by virtual keyboards?

[Tim Guan-tin Chien]

Hi Yi-Fan, Masayuki, all,

The Gaia Keyboard currently send inputs to the MozInputContext#sendKey
method. The method receives 4 arguments, keyCode, charCode, modifiers,
and repeat. Currently we always send keyCode=0 for printable keys,
however we were informed there are compatibility issues, see [1]. Spec
in [2] does suggest we should attempt to simulate the keyCode values,
if I read it correctly.

Yi-Fan have kindly enough to provide a fix to the problem, i.e. set
the keyCode to the upper case value of the corresponding charCode,
however I don't believe this is an exhaust fix. While the keyCode for
key "lower case i" is indeed equal to "upper case I", the same
transformation should not be apply to, say, lower case ï. Honestly, I
don't know what the keyCode for the character ï should be.

The iOS Safari seems to employ a mapping logic where it would only
resolve keyCode to the keyCode on US Keyboard -- it sends keyCode=0 to
some other keys, but not all. [3]

I wonder if it's that's the direction we should be taking?
Alternatively, we could implement a exhaust fix, where all layout
definitions are responsible of defining separate keyCode values (apart
from charCode to output) for all keys, to represent the hardware
keyboard they would like to simulate.

Given the fact keyCode is deprecated in the spec as well, I also
wonder if the proper fix is even worth the effort too. Need some
advice here. Thanks.


Tim

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1142893
[2] http://www.w3.org/TR/DOM-Level-3-Events-code/#keyboard-chording-virtual
[3]
iOS Safari sends the following, tested with http://jsfiddle.net/timdream/YDGgk/:
Upper case I: keyCode=73 (charCode of "I")
Lower case i: keyCode=73 (charCode of "I")
Upper case Cyrillic Zhe Ж: keyCode=1046 (charCode of "Ж")
Lower case Cyrillic Zhe ж: keyCode=1078 (charCode of "ж")
Dollar sign $: keyCode=52 (charCode of "4")
Lower case ï (press and hold "i"): keyCode=0
Bopomofo mark ㄅ: keyCode=0

[Jonas Sicking]

Adding Olli who has spent a bunch of time on keyboard related events.

In general, the events fired by the virtual keyboard should look as
similar as possible to events fired by hardware keyboards. Though of
course it's often hard to know exactly what hardware keyboards do
send.

/ Jonas

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi

[Masayuki Nakano]

Hi,

On 2015/03/16 13:12, Tim Guan-tin Chien wrote:
> Hi Yi-Fan, Masayuki, all,
>
> The Gaia Keyboard currently send inputs to the MozInputContext#sendKey
> method. The method receives 4 arguments, keyCode, charCode, modifiers,
> and repeat. Currently we always send keyCode=0 for printable keys,
> however we were informed there are compatibility issues, see [1]. Spec
> in [2] does suggest we should attempt to simulate the keyCode values,
> if I read it correctly.

Yes. It could improve the compatibility with other browsers especially
browsers for desktop.

> Yi-Fan have kindly enough to provide a fix to the problem, i.e. set
> the keyCode to the upper case value of the corresponding charCode,
> however I don't believe this is an exhaust fix. While the keyCode for
> key "lower case i" is indeed equal to "upper case I", the same
> transformation should not be apply to, say, lower case ï. Honestly, I
> don't know what the keyCode for the character ï should be.

On desktop, we decide keyCode value from an ASCII character which is
inputtable with the key with some modifiers. For example, if a key inputs:

no modifiers: U+0643
with Shift: ":"

Then, the keyCode is computed as DOM_VK_COLON from ":".

See
https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/keyCode#Printable_keys_in_standard_position
for the detail of the rules.

So, if some virtual keyboard emulates PC keyboard, it should be computed
with these rules.

However, for the others, e.g., 10 key + swipe keys should be computed
with other rules.

> The iOS Safari seems to employ a mapping logic where it would only
> resolve keyCode to the keyCode on US Keyboard -- it sends keyCode=0 to
> some other keys, but not all. [3]
>
> I wonder if it's that's the direction we should be taking?
> Alternatively, we could implement a exhaust fix, where all layout
> definitions are responsible of defining separate keyCode values (apart
> from charCode to output) for all keys, to represent the hardware
> keyboard they would like to simulate.
>
> Given the fact keyCode is deprecated in the spec as well, I also
> wonder if the proper fix is even worth the effort too. Need some
> advice here. Thanks.

I think that if we could, we should use similar keyCode values to Safari
on iOS or Chrome on Android. However, we have Firefox for Android. I
think that compatibility between our products are more important.

Anyway, web developers should use .key values rather than .keyCode
values since:

1. .keyCode mapping won't be standardized.
2. .keyCode value cannot represent all keys on typical devices.

> Tim
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1142893
> [2] http://www.w3.org/TR/DOM-Level-3-Events-code/#keyboard-chording-virtual
> [3]
> iOS Safari sends the following, tested with http://jsfiddle.net/timdream/YDGgk/:
> Upper case I: keyCode=73 (charCode of "I")
> Lower case i: keyCode=73 (charCode of "I")
> Upper case Cyrillic Zhe Ж: keyCode=1046 (charCode of "Ж")
> Lower case Cyrillic Zhe ж: keyCode=1078 (charCode of "ж")

Over 255 keyCode value is odd. They should be 0.

> Dollar sign $: keyCode=52 (charCode of "4")
> Lower case ï (press and hold "i"): keyCode=0
> Bopomofo mark ㄅ: keyCode=0
>

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