Thanks for the report and sorry for the issue... I think we should check VK_CANCEL inside PlatformKeyMap::DomKeyFromNativeImpl() as Ctrl+ScrollLock also generates VK_CANCEL for me (https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/keycodes/platform_key_map_win.cc&q=platform_key_map_win&sq=package:chromium&type=cs&l=178).

Is there any other non-printable keys that should mutate based on modifiers? (Normally we use the DomCode-to-DomKey map for non-printable keys https://code.google.com/p/chromium/codesearch#chromium/src/ui/events/keycodes/dom_us_layout_data.h&sq=package:chromium&type=cs&l=227&rcl=1463555947)

Re #2: We definitely shouldn't use the dom_us_layout_data.h map for anything in release code, since it is only valid for US English layouts.

PlatformKeyMap uses the Unicode->key mapping for printable and some non-printable keys - we should add a VKEY->key map to cope with the remaining non-printable keys. It may also be necessary to add layout-specific special-cases where some languages apply different meanings to the same non-printable VKEYs. :-(

> Is there any other non-printable keys that should mutate based on modifiers?

Any keys may be possible. IME can overwrite the virtual key code and some special keys for specific language causes valid virtual keycode only when the language's keyboard layout is active. Additionally, some body may swap the keys with keyboard utility.

So, KeyboardEvent.key should be computed with virtual keycode always.

Computing with just the virtual keyCode won't work though, e.g. you then
can't express Hebrew, Arabic, etc language input. It's necessary to look at
the character output of the printable keys to determine |key|.

If you're suggesting that we switch to deriving non-printable key values
from keyCode then that seems more reasonable. :)

Yes, I commented only about non-printable keys.

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

commit fc639eb35da440358def45719ec8573117069e87
Author: chongz <chongz@chromium.org>
Date: Fri Jun 03 17:23:21 2016

[DomKey] Use VK->DomKey mapping for non-printable keys

The original DomCode+flags->DomKey mapping causes issue when the application
generates mismatched keyCode + scanCode, or missing scanCode entirely.
(e.g. keyboard-rewrite softwares that only modifies keyCode)

A better solution is to use VK+flags->DomKey mapping (for both printable
and non-printable keys).

This CL is the first step for the non-printable keys, where a fixed table
for general non-printable keys was introduced. And there will be follow up CLs
to handle other language-specific cases and printable keys.

BUG= 612749 

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

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