NOT FOR COMMIT: Make altgr+left and altgr+right navigate back/forward on views.

ui/views/controls/textfield/textfield.cc

Index: ui/views/controls/textfield/textfield.cc
diff --git a/ui/views/controls/textfield/textfield.cc b/ui/views/controls/textfield/textfield.cc
index b31dd2d0737218a3d623dd54b9eb3ba9f2be0594..edc247de498c140efb0051003b22a6726cbd9cd4 100644
--- a/ui/views/controls/textfield/textfield.cc
+++ b/ui/views/controls/textfield/textfield.cc
@@ -844,11 +844,18 @@ void Textfield::AboutToRequestFocusFromTabTraversal(bool reverse) {
 
 bool Textfield::SkipDefaultKeyEventProcessing(const ui::KeyEvent& event) {
 #if defined(OS_LINUX) && !defined(OS_CHROMEOS)
+  // TODO: This bool needs to be set if the key corresponds to altgr+left.  
+  // Linux doesn't have a built-in shortcut for alt+left, so alt doesn't
+  // need special handling here, but altgr does even thought it doesn't do
+  // anything with the left arrow as best I can tell.
+  bool isAltGrLeftBackNavigation = true;

[ojan, 2016/05/27 00:53:54]

This is the bit of code that needs to be finished to make this work on Linux.

[Peter Kasting, 2016/05/27 01:11:01]

Let me see if I understand.  This code needs to return "true" for any keyevent
that might normally be interpreted as some kind of global shortcut, but when
this textfield is focused needs to be captured by the textfield instead, in
order to be handled as an editing-specific key event.  Specifically, this block
looks for keystrokes that have some kind of system custom editing keybinding
(e.g. vi keybindings), which should result in MatchEvent() filling the vector
it's given.

The issue is that, for some reason, MatchEvent() is always returning true for
AltGr+Left, even though it has no apparent meaning, resulting in it being
captured by the edit control, resulting in the shortcut not working when a
top-chrome textfield is focused.  Is that right?

If this is the case my question would be why MatchEvent() would return true in
this case; and how the proposed solution here would avoid the issue of the user
intentionally doing a custom keybinding for AltGr+Left and then having it not
work as expected in this edit control.

Or have I totally misunderstood what's happening?

+
   // Skip any accelerator handling that conflicts with custom keybindings.
   ui::TextEditKeyBindingsDelegateAuraLinux* delegate =
       ui::GetTextEditKeyBindingsDelegate();
   std::vector<ui::TextEditCommandAuraLinux> commands;
-  if (delegate && delegate->MatchEvent(event, &commands)) {
+  if (!isAltGrLeftBackNavigation &&
+      (delegate && delegate->MatchEvent(event, &commands))) {
     const bool rtl = GetTextDirection() == base::i18n::RIGHT_TO_LEFT;
     for (size_t i = 0; i < commands.size(); ++i)
       if (IsCommandIdEnabled(GetViewsCommand(commands[i], rtl)))