/ key is not handled correctly on Chrome on Linux

[dborowitz]

I tried to add a handler for /, but iron-a11y-keys-behavior identifies the key as U+00BF, which is an inverted question mark (https://en.wikipedia.org/wiki/U+00BF). I believe 191 is actually the JS keycode for /, it's just not getting translated properly.

I can reproduce the problem on Chrome 46 on Linux, but not on OS X. Sample code is here:
https://gerrit-review.googlesource.com/#/c/73010/1/polygerrit-ui/app/elements/gr-search-bar.html@85

I tried adding a test to basic-test.html like the following:

test('trigger the handler when slash is pressed', function() {
  MockInteractions.pressAndReleaseKeyOn(keys, 191);
  expect(keys.keyCount).to.be.equal(1);
});

but the whole test suite is failing for me so I must be doing something wrong.

My chrome://version says:

Google Chrome   46.0.2490.86 (Official Build) (64-bit)
Revision    e8926f681fbb840b4f389e7e692343d4505722ce-refs/branch-heads/2490@{#560}
OS  Linux 
Blink   537.36 (@e8926f681fbb840b4f389e7e692343d4505722ce)
JavaScript  V8 4.6.85.31
Flash   19.0.0.245
User Agent  Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36

[dborowitz]

/ is not the only key affected. For example [ shows up as U+00DB and ] is U+00DD.

[andybons]

Additionally, on Windows, [ is reported as U+00DD.

[valdrinkoshi]

event.keyCode is not reliable for special characters (e.g. on US keyboard you'd press shift and 1 to obtain ! The resulting event.keyCode is 49 which corresponds to 1, that's why we rely on event.key, then event.keyIdentifier and finally event.keyCode)

event.key should be the answer, but so far it is undefined for special characters. So next best is event.keyIdentifier.

Did some tests, on Chrome Linux the event.keyIdentifier is wrong:

# pressed /
key undefined -> 
keyIdentifier U+00BF -> ¿
keyCode 191 -> undefined

# pressed [
key undefined -> 
keyIdentifier U+00DB -> û
keyCode 219 -> undefined

On Chrome Mac instead event.keyIdentifier is correct:

# pressed /
key undefined -> 
keyIdentifier U+002F -> /
keyCode 191 -> undefined

# pressed [
key undefined -> 
keyIdentifier U+005B -> [
keyCode 219 -> undefined

Adding 191 keyCode is not an option, because it would be triggered even if we press Shift + [ (which instead matches to {).

[valdrinkoshi]

Closing this issue as it's a platform problem rather than of the behavior.
@cdata FYI

[andybons]

Have you filed a Chrome bug for this? Is the problem also present on Firefox Linux?

[dborowitz]

I'm confused as to why this bug was closed. Even if the root cause is due to a platform issue, there is surely a problem with iron-a11y-keys-behavior as well.

The documented behavior is you put a character as a key in the keyBindings object, you get a key binding for the key that generates that character. If this works only for some characters, then you need to document what subset of characters it works for.

And honestly, as an application developer, if I can't count on this library to work for every key I need to handle bindings for, I'm not likely to use it at all. Handling some key events using this behavior and some manually is more conceptual overhead than just handling everything manually.

[valdrinkoshi]

This issue happens only on Chrome on Linux and Windows, Firefox already implements event.key and returns the correct values.
I've reported the issue on chromium

@dborowitz iron-a11y-keys-behavior supports special characters to the extent of how they're supported by the platform :)
Even if you want to handle it without using this element, you'll face the same issues with other keyboard configurations.
In your case you want to listen to /: with a US keyboard you'd check for keyCode = 191 and make sure that event.shiftKey = false && event.altKey = false in order to avoid recognizing characters like ÷ (which is Alt+/) and ? (which is Shift+/).

With a French keyboard you need to press Shift+: to obtain /, so you see how difficult it becomes to handle everything properly without something like event.keyIdentifier or (even better) event.key

[valdrinkoshi]

Surprise surprise: on keypress event everything works as expected! http://jsbin.com/webogoc/4/edit?html,output

I'll reopen this issue, I'll update the demo page to use keypress for the special characters ;)

[valdrinkoshi]

Ok, closing this again. On Linux the keyIdentifier is wrongly set also for keypress, and we cannot bypass it and prefer keyCode for the reasons I exposed before

In this test i pressed / and then [, and we get the final result via normalizedKeyForEvent

[andybons]

Please re-open this as keyIdentifier is deprecated in favor of key and the Blink bug was closed as WontFix. https://crbug.com/587150

/cc @garykac

[andybons]

Hm. On Chrome Canary (52.0.2734.0) key is supported.

@valdrinkoshi will this “just work” once key is supported given the key handling code and it’s various fallbacks?

[garykac]

key is supported on Chrome 51+ and we should fix any bugs that relate to key and code. Recent versions of Opera will have this support as well. Firefox already supports both of these attributes. IE/Edge have an older implementation of key that they will be updating at some point (probably when they add support for code).

[valdrinkoshi]

Correct, the behavior will first try to use key and then the others if that's not available.

[garykac]

BTW, for looking at key events, you may want to try: https://w3c.github.io/uievents/tools/key-event-viewer.html

You can turn on keyIdentifier by selecting Options and enabling the "Old DOM3" fields.