[System-Keyboard-Lock] Add KeyboardLockHost and KeyEventInterceptor

components/keyboard_lock/keyboard_lock_host.cc

Index: components/keyboard_lock/keyboard_lock_host.cc
diff --git a/components/keyboard_lock/keyboard_lock_host.cc b/components/keyboard_lock/keyboard_lock_host.cc
new file mode 100644
index 0000000000000000000000000000000000000000..1a5404146640e302bd7c2924ef387d9881c76632
--- /dev/null
+++ b/components/keyboard_lock/keyboard_lock_host.cc
@@ -0,0 +1,58 @@
+// Copyright 2017 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 "components/keyboard_lock/keyboard_lock_host.h"
+
+#include <utility>
+
+#include "base/logging.h"
+#include "base/memory/singleton.h"
+
+namespace keyboard_lock {
+
+namespace {
+
+class HostKeyEventInterceptorRetriever : public KeyEventInterceptor::Retriever {
+ public:
+  HostKeyEventInterceptorRetriever() = default;
+  ~HostKeyEventInterceptorRetriever() override = default;
+
+  KeyEventInterceptor* Get() override;
+};
+
+KeyEventInterceptor* HostKeyEventInterceptorRetriever::Get() {
+  return KeyboardLockHost::GetInstance()->interceptor();
+}
+
+}  // namespace
+
+KeyboardLockHost::KeyboardLockHost() = default;
+KeyboardLockHost::~KeyboardLockHost() = default;
+
+// static
+KeyboardLockHost* KeyboardLockHost::GetInstance() {
+  return base::Singleton<KeyboardLockHost,
+                         base::LeakySingletonTraits<KeyboardLockHost>>::get();
+}
+
+void KeyboardLockHost::SetKeyEventInterceptor(
+    std::unique_ptr<KeyEventInterceptor> interceptor) {
+  base::AutoLock lock(lock_);

[dtapuska, 2017/04/18 13:43:17]

Are there multiple threads running around that you'd need an interceptor for? If
there are then the lifecycle of the returned pointer is bogus because it is
stored via a unique_ptr. 

If there are multiple threads then the object should be refcounted. If there
aren't then you don't need this lock.

[Hzj_jie, 2017/04/19 00:46:26]

Multiple threads are required: the interceptor will be accessed by native
message loop by X11 or low level callbacks of key events on Windows / Mac OS,
which are running on its own thread or unpredictable threads.

I believe this behavior is safe, since the KeyboardLockHost as well as the
interceptor are never destroyed because of the base::LeakySingletonTraits used
above.

[dtapuska, 2017/04/21 14:48:33]

So ultimately is this just not a construction problem. In that you want to
initialize the keyboard lock host before any threads start up? 

[Hzj_jie, 2017/04/21 21:13:09]

Sorry, it looks like I do not follow. KeyboardLockHost should only be
initialized during the first GetInstance() call, which is usually triggered by a
navigator.requestKeyLock() call.

+  DCHECK(!interceptor_);
+  DCHECK(interceptor);
+  interceptor_ = std::move(interceptor);
+}
+
+KeyEventInterceptor* KeyboardLockHost::interceptor() const {
+  base::AutoLock lock(lock_);
+  return interceptor_.get();
+}
+
+std::unique_ptr<KeyEventInterceptor::Retriever>
+KeyboardLockHost::GetInterceptorRetriever() {
+  return std::unique_ptr<KeyEventInterceptor::Retriever>(
+      new HostKeyEventInterceptorRetriever());
+}
+
+}  // namespace keyboard_lock