New issue
Advanced search Search tips

Issue 600602 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Apr 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Incorrect |code| for key events on Linux French keyboard.

Project Member Reported by garykac@chromium.org, Apr 5 2016

Issue description

Version: 49.0.2623.87 (64-bit)
OS: Linux

What steps will reproduce the problem?
(1) Linux with French 102 keyboard and French locale.
(2) Go to Keyboard Event Manual Test page for French: https://cdn.rawgit.com/w3c/uievents/gh-pages/tests/key-mtest-102fr-fr.html
(3) Click "Show Options"
(4) Make sure only 'keydown' is selected for 'Events'
(5) Make sure only 'code' is selected for 'Attributes'
(6) Start test

Press the keys as they are highlighted. Note that the '^' key (near the end of the 2nd row) is skipped because it is a dead key.
Use 'Esc' to skip keys (like 'Meta') that are trapped by the OS.


What is the expected output?
All keys pass and turn green.


What do you see instead?
The '*'  key (2nd to last on 3rd row) produces the wrong |code|: It produces 'Backslash' instead of the correct 'IntlHash'.

 
So I get a BKSL scancode for that key...

kpschoedel@; any insight?

Looking at xkbprint I get this...

xkbprint -label name $DISPLAY -

% Begin row 3
false 0 20 390 CAPS % <CAPS>
false 0 360 390 NORM % <AC01>
false 0 550 390 NORM % <AC02>
false 0 740 390 NORM % <AC03>
false 0 930 390 NORM % <AC04>
false 0 1120 390 NORM % <AC05>
false 0 1310 390 NORM % <AC06>
false 0 1500 390 NORM % <AC07>
false 0 1690 390 NORM % <AC08>
false 0 1880 390 NORM % <AC09>
false 0 2070 390 NORM % <AC10>
false 0 2260 390 NORM % <AC11>
false 0 2450 390 NORM % <BKSL>

'Backslash' is the key above Return on keyboards that have a “wide” Return key (ISO9995 position D13 == USB 07:0031 "Keyboard \ and |").

'IntlHash' is the key left of Return on keyboards that have a “tall” Return key (ISO9995 position C12 == USB 07:0032 "Keyboard Non-US # and ~").

The Linux kernel squashes both down to the same evdev code, KEY_BACKSLASH, so we can't tell them apart. See e.g. http://lxr.free-electrons.com/source/drivers/hid/hid-input.c#L43

Judging by the comment in keycode_converter_data.inc at https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/keycodes/dom/keycode_converter_data.inc&l=181 both Windows and OS X do likewise.

Basically, it's an OS problem, and there's nothing Chrome can do about it.

Status: WontFix (was: Assigned)
OK. It actually then becomes a spec bug.

That comment was written with the assumption that the browser would be able to distinguish between 'IntlHash' and 'Backslash'. But if the browser cannot reasonably distinguish between them, then it sounds like we need to remove 'IntlHash' from the UI Event spec and always return 'Backslash' for both of these keys.

I have removed IntlHash from the latest ED of the UI Events spec: https://w3c.github.io/uievents-code/
Labels: Hotlist-Input-Dev

Sign in to add a comment