Take GetCharacterFromKeyCode() out behind the barn.

ui/events/test/event_generator.cc

Index: ui/events/test/event_generator.cc
diff --git a/ui/events/test/event_generator.cc b/ui/events/test/event_generator.cc
index ae3bcb6d667a786c82a7e55a47d290835d3c1898..68650154b5b9e4659f27459cc4566640ca7bf400 100644
--- a/ui/events/test/event_generator.cc
+++ b/ui/events/test/event_generator.cc
@@ -540,7 +540,8 @@ void EventGenerator::DispatchKeyEvent(bool is_press,
                                       int flags) {
 #if defined(OS_WIN)
   UINT key_press = WM_KEYDOWN;
-  uint16 character = ui::GetCharacterFromKeyCode(key_code, flags);
+  uint16 character = ui::DomCodeToUsLayoutCharacter(
+      ui::UsLayoutKeyboardCodeToDomCode(key_code), flags);

[Wez, 2015/04/21 22:08:46]

This changes the behaviour slightly - e.g. the top-level alpha key on a PC
keyboard will generate Q (US English) or A (French layout) with the old code,
since it's based on the VKEY, while this implementation will always generate Q.

Is that an issue? More generally, is the fact that this code path is US English
only an issue right now?

[kpschoedel, 2015/04/21 22:36:38]

GetCharacterFromKeyCode() was a hard-coded US layout as well.
|DomCodeToUsLayoutCharacter(UsLayoutKeyboardCodeToDomCode())| should always
return the same character as |GetCharacterFromKeyCode()| did, but I'll write a
temporary test to verify that before landing this change.

   if (is_press && character) {
     MSG native_event = { NULL, WM_KEYDOWN, key_code, 0 };
     TestKeyEvent keyev(native_event, flags);