Needs clearer definition of virtual keyboard's KeyboardEvent.code value if it doesn't emulate physical key event completely

[garykac]

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25968

Masayuki Nakano 2014-06-04 00:43:55 UTC

[09:33] If a VKB doesn't emulate native physical key event completely, there are 2 patterns:
[09:34] One is there is an API to compute scancode from virtual keycode. This is Windows' case. At this time, browsers can use the API and compute .code value from the result.
[09:35] I filed a bug for us to start investigating tests: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25967
[09:36] The other is, the is not such API. E.g., Android. At this time, browsers can guess non-printable keys and some printable keys which can guess the key position from virtual keycode name. E.g., it has NUMPAD or something.
[09:36] I don't expect all VKBs to provide useful 'code' values for every key.
[09:36] They should if they want to emulate a physical keyboard, but not all VKBs care about that.
[09:37] In the latter case, browsers should NOT set .code values for printable keys which must be in standard position because VK -> SC depends on keyboard layout.
[09:39] https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#code-virtual-keyboards
[09:39] VKBs that emulate a physical keyboard should be emulating a particular layout as well - so they should know what positions to use.
[09:39] This looks like that D3E spec recommends that browsers should guess the key position even in such case.
[09:40] So I would expect a virtual french keyboard (with standard layout) to use 'KeyA' for the key labeled 'q'.
[09:41] If they completely change the layout for the VKB, then the 'code' doesn't have much use.
[09:41] I'd like you to document about the latter case in the spec even if the VKB looks like emulating physical keyboard but not generating scancode properly.

Comment 1 Masayuki Nakano 2014-06-04 00:54:11 UTC

My most important suggestion is, browsers SHOULD NOT try to guess code values of printable keys in standard position when a VKB doesn't emulate native physical keyboard event (i.e., no scancode) and the platform doesn't have API to compute scancode from virtual keycode.

If browsers did guess in such case, .code value would be untrusted attribute in such situation but web developers couldn't know whether they were in such case.

Comment 2 Masayuki Nakano 2014-06-04 01:24:56 UTC

And Olli thinks that it's odd to guess non-printable .code value when browsers are not sure the printable keys' code values.
https://bugzilla.mozilla.org/show_bug.cgi?id=1017383#c2

I think that it's okay browsers to set proper code value when a native virtual keycode includes position information e.g., SHIFT_LEFT, SHIFT_RIGHT, or is only generated with a scan value like SPACE.

However, indeed, if browsers shouldn't guess code value always, it makes the spec and behavior simpler.

Comment 3 Arthur Barstow 2015-03-21 15:11:57 UTC

Bulk move of all D3E bugs to the UI Events component.

[garykac]

This issue was moved to w3c/uievents-code#2