The browser test GlobalKeyboardShortcutsTest.MenuCommandPriority fails when ViewsBrowserMode is enabled.

This test is checking that user key equivalents (added via System Preferences > Keyboard > Shortcuts) can replace browser hotkeys. It fails in ViewsBrowserMode because this logic in [ChromeCommandDispatcherDelegate prePerformKeyEquivalent:window:] behaves incorrectly in Views mode:

  // If a command has a menu key equivalent that *replaces* one of the window
  // keyboard shortcuts, the menu key equivalent needs to be executed, because
  // these are user-addded keyboard shortcuts that replace builtin shortcuts.
  //
  // If a command has a menu key equivalent that does *not* replace a window
  // keyboard shortcut, it will be handled later; only window shortcuts need
  // special handling here since they happen before normal command dispatch.
  int cmd = MenuCommandForKeyEvent(event);
  if (cmd != -1) {
    int keyCmd = CommandForExtraKeyboardShortcut(
        event, window, CommandForWindowKeyboardShortcut);
    Browser* browser = chrome::FindBrowserWithWindow(window);
    if (keyCmd != -1 && browser) {
      chrome::ExecuteCommand(browser, cmd);
      return YES;
    }
  }

In the Views browser, hotkeys still go through this code path, but the command table used for CommandForWindowKeyboardShortcut() is far less extensive, because most of the browser hotkeys are actually in accelerator_table.cc's kAcceleratorMap. This prevents this logic from detecting when a user shortcut aliases a browser hotkey. The simplest fix is to have CommandForWindowKeyboardShortcut also consult kAcceleratorMap, but I think this will run afoul of the Cocoa-side GetDelayedWindowKeyboardShortcutTable logic - the Cocoa browser has multiple "phases" of hotkeys, which are not reflected in kAcceleratorMap. There's another issue with that approach too: kAcceleratorMap duplicates many hotkeys that appear in menu key equivalents, so wiring up kAcceleratorMap here causes the "user hotkey override" code path to trigger for nearly all hotkeys, which is clearly not right. Perhaps the answer is to have a Mac-specific version of kAcceleratorMap with most of the bindings hacked out?

Over to erikchen@, who is working on other hotkey stuff.