Fix some surprising reverse key mappings.

chrome/browser/chromeos/events/event_rewriter.cc

Index: chrome/browser/chromeos/events/event_rewriter.cc
diff --git a/chrome/browser/chromeos/events/event_rewriter.cc b/chrome/browser/chromeos/events/event_rewriter.cc
index 9697cb9b758879056697801ba265378afef7d64c..4bfd4495b47c9226f3a33b7797deacc1110e32a6 100644
--- a/chrome/browser/chromeos/events/event_rewriter.cc
+++ b/chrome/browser/chromeos/events/event_rewriter.cc
@@ -395,10 +395,13 @@ ui::EventRewriteStatus EventRewriter::RewriteKeyEvent(
     CHECK(xev->type == KeyPress || xev->type == KeyRelease);
     XKeyEvent* xkey = &(xev->xkey);
     UpdateX11EventMask(rewritten_key_event->flags(), &xkey->state);
-    xkey->keycode =
-        XKeysymToKeycode(gfx::GetXDisplay(),
-                         ui::XKeysymForWindowsKeyCode(
-                             state.key_code, state.flags & ui::EF_SHIFT_DOWN));
+    // 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() != state.key_code) {
+      xkey->keycode = XKeysymForWindowsKeyCode(

[Daniel Erat, 2014/07/08 14:49:31]

s/XKeysym/XKeyCode/

[kpschoedel, 2014/07/08 16:44:50]

Drat. Nothing broke because it was an unambiguous overload.

+          state.key_code, state.flags, gfx::GetXDisplay());
+    }
   }
 #endif
   return status;