Refactor compositor event handling path to be callback-based

content/renderer/input/input_handler_manager.h

Index: content/renderer/input/input_handler_manager.h
diff --git a/content/renderer/input/input_handler_manager.h b/content/renderer/input/input_handler_manager.h
index 060f7c58caf13a371144b179e09b88a4a65ce25c..bcf94d698ad618d11804a06420a555876468c8b5 100644
--- a/content/renderer/input/input_handler_manager.h
+++ b/content/renderer/input/input_handler_manager.h
@@ -10,7 +10,9 @@
 #include "base/memory/weak_ptr.h"
 #include "content/common/content_export.h"
 #include "content/common/input/input_event_ack_state.h"
+#include "content/renderer/input/input_handler_manager_client.h"
 #include "content/renderer/render_view_impl.h"
+#include "ui/events/blink/input_handler_proxy.h"
 
 namespace base {
 class SingleThreadTaskRunner;
@@ -40,8 +42,6 @@ namespace content {
 
 class InputHandlerWrapper;
 class SynchronousInputHandlerProxyClient;
-class InputHandlerManagerClient;
-struct DidOverscrollParams;
 
 // InputHandlerManager class manages InputHandlerProxy instances for
 // the WebViews in this renderer.
@@ -79,14 +79,18 @@ class CONTENT_EXPORT InputHandlerManager {
   // Callback only from the compositor's thread.
   void RemoveInputHandler(int routing_id);
 
+  using InputEventAckStateCallback =
+      InputHandlerManagerClient::InputEventAckStateCallback;
   // Called from the compositor's thread.
-  virtual InputEventAckState HandleInputEvent(
-      int routing_id,
-      const blink::WebInputEvent* input_event,
-      ui::LatencyInfo* latency_info);
+  virtual void HandleInputEvent(int routing_id,
+                                ui::ScopedWebInputEvent input_event,
+                                const ui::LatencyInfo& latency_info,
+                                const InputEventAckStateCallback& callback);
 
   // Called from the compositor's thread.
-  void DidOverscroll(int routing_id, const ui::DidOverscrollParams& params);
+  void DidOverscroll(int routing_id,

[dtapuska, 2016/08/23 19:34:10]

I find this DidOverscroll vs DidHandleInputEvent confusing. I wonder if the
callback should be something like a progress callback.

If there is an event associated with the callback then an InputEventAck will be
sent. If there is no associated event; then send the InputHostMsg_DidOverscroll.

I know you researched whether we could just do a direct class callback and that
the problem was that mus wanted to be an alternate handler for input messages.
Can MUS and Chrome IPC be used at the same time? If not I wonder if this could
just be setting the client interface to a new handle.

tdresser@ thoughts; callbacks seem to generate spaghetti code callgraphs to me.

[chongz, 2016/08/23 23:40:33]

I've also updated the design doc (@chromium) which discussed some tradeoffs for
the approach.
PTAL, thanks!
https://docs.google.com/a/chromium.org/document/d/1SUPPJkqxEYMRso3Jw1wZnqD3g1...

+                     const ui::DidOverscrollParams& params,
+                     bool bundle_ack_with_triggering_event);
 
   // Called from the compositor's thread.
   void DidStartFlinging(int routing_id);
@@ -117,6 +121,14 @@ class CONTENT_EXPORT InputHandlerManager {
       const blink::WebGestureEvent& gesture_event,
       const cc::InputHandlerScrollResult& scroll_result);
 
+  using EventDisposition = ui::InputHandlerProxy::EventDisposition;
+  void DidHandleInputEvent(
+      const InputEventAckStateCallback& callback,
+      EventDisposition event_disposition,
+      ui::ScopedWebInputEvent input_event,
+      const ui::LatencyInfo& latency_info,
+      std::unique_ptr<ui::DidOverscrollParams> overscroll_params);
+
   typedef base::ScopedPtrHashMap<int,  // routing_id
                                  std::unique_ptr<InputHandlerWrapper>>
       InputHandlerMap;