FYI: In TSF mode, keydown event isn't fired on Firefox for the keys (this is a long standing bug of Firefox). You can test Firefox behavior with IMM mode:

1. Load about:config
2. filter the prefs with "tsf"
3. Set intl.tsf.enable to false (double click it)
4. Restart Firefox

Additionally, those keys cause same key value even if I activate non-Japanese keyboard layout. That's really wrong behavior. For example, in en-US locale, KanaMode, KanjiMode, etc are never available.

Looks like that these key values are mapped from "code" value (or scancode)?

FYI: And also VK_CONVERT and VK_NONCONVERT are not mapped in non-Japanese keyboard layout but Chrome maps "Convert" key and "NonConvert" key to "Convert" and "NonConvert" too. Chrome should stop this too. KeyboardEvent.key should be computed from virtual key code since it represents the "function" of the pressed key under current condition (depending on keyboard layout, modifier state, OS, etc).

Surprising that cases 4,5,6 don't work as expected; the platform key-map for Windows does determine the behaviour of the layout under different modifiers - sounds like Windows may be generating the same Unicode character regardless of modifiers, and distinguishing the function exclusively via the VKEY code.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9d990a45f12393c2e557d4b33116b5ce1022b403

commit 9d990a45f12393c2e557d4b33116b5ce1022b403
Author: chongz <chongz@chromium.org>
Date: Mon Jul 11 20:06:47 2016

[DomKey] Support Japanese (JIS) layout special keys

This CL adds mappings for for keys specific to Japanese (JIS) layouts:

1. "半角/全角\n漢字"
(DomKey::HANKAKU/ZENKAKU/KANJI_MODE, DomCode::BACKQUOTE, to the left of Digit1)
Used to switch between Hankaku, Zenkaku and KanjiMode, may use with Alt.

2. "Caps Lock\n英数"
(DomKey::ALPHANUMERIC/HIRAGANA, DomCode::CAPS_LOCK, same location as CapsLock)
Used to switch between Alphanumeric and Hiragana.

3. "カタカナ\nひらがな\nローマ字"
(DomKey::KATAKANA/HIRAGANA/ROMAJI, DomCode::KANA_MODE, to the left of AltRight)
Used to switch between Katakana, Hiragana and Romaji, may use with Alt or Shift

(We don't need to handle Convert/NonConvert specially but could simply put them into the generic mapping table. The reason is their VKEYs are unique and clear - VK_CONVERT/VK_NONCONVERT, and the OS won't produce those VKEYs if they are not supported by current layout. e.g. Will produce 0xff on US layout)

Since the VKEYs for these keys express their correct meanings, taking into account modifiers and lock states, we can use a static table to map them to DomKey values.

See the BUG for how JIS keyboard works and how to produce these values...

Note:
Sometimes pressing a key will cause 'keyup' events that does not match this key, this is known and actually means we are leaving the previous state.
e.g. Press Alphanumeric key first, and then if you hit Hiragana key you will actually get a keyup for Alphanumeric key, which means you are leaving Alphanumeric state.

BUG= 612694 

Review-Url: https://codereview.chromium.org/2128573002
Cr-Commit-Position: refs/heads/master@{#404715}

[modify] https://crrev.com/9d990a45f12393c2e557d4b33116b5ce1022b403/ui/events/keycodes/keyboard_codes_posix.h
[modify] https://crrev.com/9d990a45f12393c2e557d4b33116b5ce1022b403/ui/events/keycodes/keyboard_codes_win.h
[modify] https://crrev.com/9d990a45f12393c2e557d4b33116b5ce1022b403/ui/events/keycodes/platform_key_map_win.cc
[modify] https://crrev.com/9d990a45f12393c2e557d4b33116b5ce1022b403/ui/events/keycodes/platform_key_map_win_unittest.cc