refactoring mouse lock to support pepper and WebKit

content/renderer/mouse_lock_dispatcher.h

+// 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.
+
+#ifndef CONTENT_RENDERER_MOUSE_LOCK_DISPATCHER_H_
+#define CONTENT_RENDERER_MOUSE_LOCK_DISPATCHER_H_
+#pragma once
+
+#include "base/basictypes.h"
+#include "content/public/renderer/render_view_observer.h"
+
+class RenderViewImpl;
+
+namespace WebKit {
+class WebMouseEvent;
+class WebWidget;
+}  // namespace WebKit
+
+namespace webkit{
+namespace ppapi {
+class PluginInstance;
+}  // namespace ppapi
+}  // namespace webkit
+
+// MouseLockDispatcher is owned by RenderViewImpl.
+class MouseLockDispatcher : public content::RenderViewObserver {
+ public:
+  explicit MouseLockDispatcher(RenderViewImpl* render_view_impl);
+  virtual ~MouseLockDispatcher();
+
+  bool LockMouse(WebKit::WebWidget* webwidget,
+                 webkit::ppapi::PluginInstance* plugin);
+  void UnlockMouse(WebKit::WebWidget* webwidget,
+                   webkit::ppapi::PluginInstance* plugin);
+  bool IsPointerLockedTo(WebKit::WebWidget* webwidget);
+  bool IsMouseLockedTo(webkit::ppapi::PluginInstance* plugin);

[piman, 2012/01/18 19:00:59]

On these 2 functions, they seem identical except for the type of owner.
Shouldn't they have the same name (tagged with a type for the overload)?
e.g. IsMouseLockedToWebWidget/IsMouseLockedToPluginInstance ?

[scheib, 2012/01/24 01:51:42]

Refactoring has resulted in only one set of functions, with the two differing
interfaces (pepper, webwidget) encapsulated in LockTarget subclasses.

+  bool WillHandleMouseEvent(const WebKit::WebMouseEvent& event);
+
+ private:
+  // RenderView::Observer implementation.
+  virtual bool OnMessageReceived(const IPC::Message& message) OVERRIDE;
+
+  // IPC handlers.
+  void OnLockMouseACK(bool succeeded);
+  void OnMouseLockLost();
+
+  bool MouseLockedOrPendingAction() const {
+    return mouse_locked_ || pending_lock_request_ || pending_unlock_request_;
+  }
+
+  RenderViewImpl* render_view_impl_;
+
+  bool mouse_locked_;
+  // If both |pending_lock_request_| and |pending_unlock_request_| are true,
+  // it means a lock request was sent before an unlock request and we haven't
+  // received responses for them.
+  // The logic in LockMouse() makes sure that a lock request won't be sent when
+  // there is a pending unlock request.
+  bool pending_lock_request_;
+  bool pending_unlock_request_;
+
+  // |mouse_lock_webwidget_owner_| and |mouse_lock_plugin_owner_|
+  // store one (and only one) of the possible current owners of mouse lock.
+  // If they are non-NULL it doesn't indicate that the mouse has been locked,
+  // a pending request to lock the mouse can be outstanding.
+  // The objects are not owned by this class.
+  //
+  // Direct reference to two different possible owners is a trade off compared
+  // to adding a common interface both can inherit. The WebWidget would also
+  // require a wrapper to avoid adding the interface to the WebKit API. In
+  // total the abstraction would require more code than directly managing the
+  // two types of lock owner, and we have decided against adding that
+  // complexity.
+  WebKit::WebWidget* mouse_lock_webwidget_owner_;

[piman, 2012/01/18 19:00:59]

Looking at the code, it seems that the only possible webwidget  owner would be
render_view_impl_'s webwidget. It seems that we could simplify the logic a
little bit by always going through the RenderViewImpl to get to the webwidget
(and that may help with lifetime issues), making this a bool
"render_view_is_owner_" or something.

[scheib, 2012/01/24 01:51:42]

Refactoring has removed this issue, there is only one target now.

+  webkit::ppapi::PluginInstance* mouse_lock_plugin_owner_;
+
+  DISALLOW_COPY_AND_ASSIGN(MouseLockDispatcher);
+};
+
+#endif  // CONTENT_RENDERER_MOUSE_LOCK_DISPATCHER_H_