Fix WebView compositor input handling

content/renderer/android/synchronous_input_event_filter.cc

Index: content/renderer/android/synchronous_input_event_filter.cc
diff --git a/content/renderer/android/synchronous_input_event_filter.cc b/content/renderer/android/synchronous_input_event_filter.cc
new file mode 100644
index 0000000000000000000000000000000000000000..b2b517540956400984a1e3f9f6c816420abe6082
--- /dev/null
+++ b/content/renderer/android/synchronous_input_event_filter.cc
@@ -0,0 +1,54 @@
+// 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.
+
+#include "content/renderer/android/synchronous_input_event_filter.h"
+
+#include "base/callback.h"
+#include "base/logging.h"
+
+using WebKit::WebInputEvent;
+
+namespace content {
+
+SynchronousInputEventFilter::SynchronousInputEventFilter() {
+}
+
+SynchronousInputEventFilter::~SynchronousInputEventFilter() {
+}
+
+InputEventAckState SynchronousInputEventFilter::HandleInputEvent(
+    int routing_id,
+    const WebKit::WebInputEvent* input_event) {
+  // The handler will be empty both before renderer initialization and after
+  // renderer destruction. It's possible that this will be reached in such a
+  // state. While not good, it should also not be fatal.
+  if (handler_.is_null())
+    return INPUT_EVENT_ACK_STATE_NO_CONSUMER_EXISTS;
+
+  // Clear the result for the (unexpected) case that callbacks to
+  // did/didNotHandleInputEvent are not made synchronously.
+  event_result_ = INPUT_EVENT_ACK_STATE_UNKNOWN;
+
+  // It is expected that handler_ initiates a synchronous callback to
+  // Did/DidNotHandleInputEvent.
+  handler_.Run(routing_id, input_event);
+  DCHECK(event_result_ != INPUT_EVENT_ACK_STATE_UNKNOWN);
+
+  return event_result_;
+}
+
+void SynchronousInputEventFilter::DidBind(const Handler& handler) {
+  handler_ = handler;

[joth, 2013/05/31 18:05:08]

this is called on main thread, but HandleInputEvent() above is on compositor
thread. DO we need a lock around hander_ or is there something to guarantee this
does not race? (I don't think there is, ya know)

also..... devil's advocate, what happens if DidBind is called a second time
(with null handler) exactly while the compositor thread is in the middle of a
call to handler_.Run() above? If we use a lock, we dead lock. Without, we are
calling into an object that is going to become invalid while we're calling it.
(Can we simplify a log but just discount the binding ever going away? Make it
official that the manager and its client must both live forever and never get
unbound, and be done? question for the cc folks)

[jdduke (slow), 2013/05/31 20:48:24]

Adding a PostTask for assigning the handler.  This handles initialization, but
not shutdown, which should be sufficient?

+}
+
+void SynchronousInputEventFilter::DidHandleInputEvent() {
+  event_result_ = INPUT_EVENT_ACK_STATE_CONSUMED;
+}
+
+void SynchronousInputEventFilter::DidNotHandleInputEvent(bool send_to_widget) {
+  event_result_ = send_to_widget ? INPUT_EVENT_ACK_STATE_NOT_CONSUMED
+                                 : INPUT_EVENT_ACK_STATE_NO_CONSUMER_EXISTS;
+}
+
+}  // namespace content