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

ui/views/controls/textfield/textfield.cc

 // Copyright (c) 2012 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 "ui/views/controls/textfield/textfield.h"
 
 #include <string>
 #include <utility>
 
 #include "base/trace_event/trace_event.h"
@@ skipping 826 matching lines @@
 bool Textfield::CanHandleAccelerators() const {
   return GetRenderText()->focused() && View::CanHandleAccelerators();
 }
 
 void Textfield::AboutToRequestFocusFromTabTraversal(bool reverse) {
   SelectAll(false);
 }
 
 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)))
         return true;
   }
 #endif
 
   // Skip backspace accelerator handling; editable textfields handle this key.
   // Also skip processing Windows [Alt]+<num-pad digit> Unicode alt-codes.
   const bool is_backspace = event.key_code() == ui::VKEY_BACK;
@@ skipping 1063 matching lines @@
     RequestFocus();
   model_->MoveCursorTo(mouse);
   if (!selection_clipboard_text.empty()) {
     model_->InsertText(selection_clipboard_text);
     UpdateAfterChange(true, true);
   }
   OnAfterUserAction();
 }
 
 }  // namespace views