Support non-US layout for rewriting Numpad key events.

chrome/browser/chromeos/events/event_rewriter.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/chromeos/events/event_rewriter.h"
 
 #include <vector>
 
 #include "ash/sticky_keys/sticky_keys_controller.h"
 #include "ash/wm/window_state.h"
@@ skipping 194 matching lines @@
   XEvent* xev = key_event.native_event();
   if (xev) {
     XEvent xkeyevent;
     // Convert all XI2-based key events into X11 core-based key events,
     // until consumers no longer depend on receiving X11 core events.
     if (xev->type == GenericEvent)
       ui::InitXKeyEventFromXIDeviceEvent(*xev, &xkeyevent);
     else
       xkeyevent.xkey = xev->xkey;
 
-    // Update native event to match rewritten |ui::Event|.
-    // The X11 keycode represents a physical key position, so it shouldn't
-    // change unless we have actually changed keys, not just modifiers.
-    // This is one guard against problems like crbug.com/390263.
-    if (key_event.key_code() != key_code) {
+    // The X11 keycode for numpad keys should always NOT be changed because

[Yusuke Sato, 2014/08/08 01:04:09]

Would you mind adding tests for this? (numpad, numpad+shift, and non-numpad
cases).

Since the change is very subtle, it's probably difficult to prevent regressions
unless you add some tests now.

[Shu Chen, 2014/08/08 05:44:09]

Actually there are test failure for this change. I've changed the solution to
much safer one, which avoid diverge between native_event's keycode and
ui::KeyEvent's key_code.
To touch the new logic by tests, we should setup non-US keyboard layout on X11
server, which is hard.
So I would prefer to skip the test for the new solution.

+    // XKeyCodeForWindowsKeyCode method cannot handle non-US keyboard layout.
+    // The original X11 keycode should be correct to get the correct keysym.

[Yusuke Sato, 2014/08/08 01:04:09]

This works because ui:: keycode is for accelerators and X11's is for text input,
right? If so, please mention that.

[Shu Chen, 2014/08/08 05:44:09]

With new solution, no need to add such comments.

+    // For SHIFT+NumpadKey cases, use the US keyboard layout.
+    // Please see crbug.com/335644.
+    if (key_code >= ui::VKEY_NUMPAD0 && key_code <= ui::VKEY_DIVIDE) {
+      if (flags & ui::EF_SHIFT_DOWN) {
+        flags &= ~ui::EF_SHIFT_DOWN;
+        xkeyevent.xkey.keycode =
+            XKeyCodeForWindowsKeyCode(key_code, flags, gfx::GetXDisplay());
+      }
+    } else if (key_event.key_code() != key_code) {
+      // Update native event to match rewritten |ui::Event|.
+      // The X11 keycode represents a physical key position, so it shouldn't
+      // change unless we have actually changed keys, not just modifiers.
+      // This is one guard against problems like crbug.com/390263.
       xkeyevent.xkey.keycode =
           XKeyCodeForWindowsKeyCode(key_code, flags, gfx::GetXDisplay());
     }
     ui::KeyEvent x11_key_event(&xkeyevent);
     rewritten_key_event = new ui::KeyEvent(x11_key_event);
   }
 #endif
   if (!rewritten_key_event)
     rewritten_key_event = new ui::KeyEvent(key_event);
   rewritten_key_event->set_flags(flags);
@@ skipping 610 matching lines @@
     KeyboardDeviceAddedInternal(device_info[i].deviceid, device_info[i].name);
   }
 
   XIFreeDeviceInfo(device_info);
 #else
   KeyboardDeviceAddedInternal(device_id, "keyboard");
 #endif
 }
 
 }  // namespace chromeos