Implement first part of supporting global extension commands.

chrome/browser/extensions/global_shortcut_listener_win.cc

Index: chrome/browser/extensions/global_shortcut_listener_win.cc
diff --git a/chrome/browser/extensions/global_shortcut_listener_win.cc b/chrome/browser/extensions/global_shortcut_listener_win.cc
new file mode 100644
index 0000000000000000000000000000000000000000..db5a973ba33238cb681ba23280ecaf676103f657
--- /dev/null
+++ b/chrome/browser/extensions/global_shortcut_listener_win.cc
@@ -0,0 +1,80 @@
+// Copyright (c) 2013 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/extensions/global_shortcut_listener_win.h"
+
+#include "base/win/win_util.h"
+#include "content/public/browser/browser_thread.h"
+#include "ui/base/accelerators/accelerator.h"
+#include "ui/base/events/event_constants.h"
+#include "ui/base/keycodes/keyboard_code_conversion_win.h"

[zhchbin, 2013/09/20 07:49:23]

This file has been moved from base to events. s/base/events.

+
+using content::BrowserThread;
+
+namespace {
+
+static base::LazyInstance<extensions::GlobalShortcutListenerWin> instance =
+    LAZY_INSTANCE_INITIALIZER;
+
+}  // namespace
+
+namespace extensions {
+
+// static
+GlobalShortcutListener* GlobalShortcutListener::GetInstance() {
+  CHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
+  return instance.Pointer();
+}
+
+GlobalShortcutListenerWin::GlobalShortcutListenerWin()
+    : keyboard_hook_(NULL),
+      is_hooking_(false) {
+  CHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
+}
+
+GlobalShortcutListenerWin::~GlobalShortcutListenerWin() {
+  if (is_hooking_)
+    StopHooking();
+}
+
+void GlobalShortcutListenerWin::StartHooking() {
+  if (is_hooking_)
+    return;
+
+  keyboard_hook_ = SetWindowsHookEx(WH_KEYBOARD_LL, &KeyboardHook, NULL, 0L);

[zhchbin, 2013/09/20 07:49:23]

Do you mind explaining the reason that you chose using hook procedure that
monitors low-level keyboard input events, instead of "RegisterHotKey" [0]?

On of my concerns is that it's too powerful. For example, suppose an native
application (Not Chrome) is using "RegisterHotKey" to register "Ctrl+Shift+Z"
and the API return true. In the meantime, an extension suggesting using global
"Ctrl+Shift+Z" is installed, suppose the command can register successfully. Now
what's happening? The hotkey of native application stops working anymore because
we "stolen" the keyboard event currently. Also thinking about a developer who is
developing a native application that using "RegisterHotKey" to enable his hotkey
"Ctrl+Shift+Z" functionality, the API return true, but why it didn't work?

By the way using hook procedure will make enabling global media keys will be
easier.

[0]:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms646309(v=vs.85).aspx

[Finnur, 2013/09/20 13:01:12]

I haven't fully made up my mind yet (and not fully thought it through either). 

This approach is dead simple and fits well in the current implementation. 

Using RegisterHotKey, on the other hand, requires a window and a messageloop,
which probably means shunting the work to another thread unless we want to have
the handler logic live outside these classes (capture WM_HOTKEY in the main
window handler code). :/

There's a clear benefit (with RegisterHotkey) to getting an error if another app
has registered the same hotkey. But I need to figure out if I can do this
without too much surgery...

On 2013/09/20 07:49:23, zhchbin wrote:

[Finnur, 2013/09/20 13:15:56]

Well, I take that back: a window isn't required. But we'll still need a separate
thread as we don't want to run the messageloop on the UI thread.

On 2013/09/20 13:01:12, Finnur wrote:

[zhchbin, 2013/09/21 02:07:50]

We can use base::win::MessageWindow to subscribe to WM_HOTKEY messages here. Or
gfx::SingletonHwnd. It seems to fit our requirement here.

On 2013/09/20 13:15:56, Finnur wrote:

[Finnur, 2013/09/21 12:23:50]

Yes, I came to the conclusion after responding to you yesterday that
RegisterHotkey is probably the way to go. SingletonHwnd is what we need, I
believe, and I got it working on Friday just before leaving. Need to polish it
up on Monday.

+  if (keyboard_hook_)
+    is_hooking_ = true;
+}
+
+void GlobalShortcutListenerWin::StopHooking() {
+  if (!is_hooking_)
+    return;
+
+  if (keyboard_hook_)
+    UnhookWindowsHookEx(keyboard_hook_);
+  keyboard_hook_ = NULL;
+  is_hooking_ = false;
+}
+
+// static
+LRESULT CALLBACK GlobalShortcutListenerWin::KeyboardHook(int code,
+                                                         WPARAM w_param,
+                                                         LPARAM l_param) {
+  if (code >= 0 && w_param == WM_KEYDOWN) {
+    int vkCode = reinterpret_cast<KBDLLHOOKSTRUCT*>(l_param)->vkCode;
+    int modifiers = 0;
+    modifiers |= base::win::IsShiftPressed() ? ui::EF_SHIFT_DOWN : 0;
+    modifiers |= base::win::IsCtrlPressed() ? ui::EF_CONTROL_DOWN : 0;
+    modifiers |= base::win::IsAltPressed() ? ui::EF_ALT_DOWN : 0;
+    ui::Accelerator accelerator(
+        ui::KeyboardCodeForWindowsKeyCode(vkCode), modifiers);
+
+    if (instance.Get().NotifyKeyPressed(accelerator))
+      return -1;  // Prevent further processing.
+  }
+
+  return CallNextHookEx(NULL, code, w_param, l_param);
+}
+
+}  // namespace extensions