This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25968 - Needs clearer definition of virtual keyboard's KeyboardEvent.code value if it doesn't emulate physical key event completely
Summary: Needs clearer definition of virtual keyboard's KeyboardEvent.code value if it...
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - UI Events (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Gary Kacmarcik
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-04 00:43 UTC by Masayuki Nakano
Modified: 2015-10-07 04:14 UTC (History)
4 users (show)

See Also:

Attachments

Description Masayuki Nakano 2014-06-04 00:43:55 UTC 
[09:33] <masayuki> If a VKB doesn't emulate native physical key event completely, there are 2 patterns:
[09:34] <masayuki> 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] <Travis> I filed a bug for us to start investigating tests: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25967
[09:36] <masayuki> 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] <garykac> I don't expect all VKBs to provide useful 'code' values for every key.
[09:36] <garykac> They should if they want to emulate a physical keyboard, but not all VKBs care about that.
[09:37] <masayuki> 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] <masayuki> https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#code-virtual-keyboards
[09:39] <garykac> VKBs that emulate a physical keyboard should be emulating a particular layout as well - so they should know what positions to use.
[09:39] <masayuki> This looks like that D3E spec recommends that browsers should guess the key position even in such case.
[09:40] <garykac> So I would expect a virtual french keyboard (with standard layout) to use 'KeyA' for the key labeled 'q'.
[09:41] <garykac> If they completely change the layout for the VKB, then the 'code' doesn't have much use.
[09:41] <masayuki> 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.
Comment 4 Gary Kacmarcik 2015-10-07 04:14:40 UTC 
Now tracking as: https://github.com/w3c/uievents/issues/26