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