Re-enable Eager Gesture Recognition on Aura

ui/events/gesture_detection/touch_disposition_gesture_filter.cc

Index: ui/events/gesture_detection/touch_disposition_gesture_filter.cc
diff --git a/ui/events/gesture_detection/touch_disposition_gesture_filter.cc b/ui/events/gesture_detection/touch_disposition_gesture_filter.cc
index 564d014a4c5f94c28a7bd9a72be4ec1c8c84d594..2c7f6ae24394f196997958bf06ac79f450ff559f 100644
--- a/ui/events/gesture_detection/touch_disposition_gesture_filter.cc
+++ b/ui/events/gesture_detection/touch_disposition_gesture_filter.cc
@@ -170,7 +170,8 @@ TouchDispositionGestureFilter::OnGesturePacket(
   return SUCCESS;
 }
 
-void TouchDispositionGestureFilter::OnTouchEventAck(bool event_consumed) {
+void TouchDispositionGestureFilter::OnTouchEventAckForQueueFront(
+    bool event_consumed) {
   // Spurious touch acks from the renderer should not trigger a crash.
   if (IsEmpty() || (Head().empty() && sequences_.size() == 1))
     return;
@@ -207,6 +208,23 @@ void TouchDispositionGestureFilter::OnTouchEventAck(bool event_consumed) {
     FilterAndSendPacket(packet);
   }
   DCHECK(touch_packet_for_current_ack_handled);
+
+  // If the next event has already been acked, process it.
+  if (!sequence.empty() &&

[jdduke (slow), 2014/11/25 20:26:37]

If we have a a whole gesture queued that was ack'ed synchronously, we might hit
some nasty recursion here, not sure what the simplest solution is though.

[tdresser, 2014/11/26 15:17:18]

Done.

+      sequence.front().ack_state() !=
+          GestureEventDataPacket::AckState::PENDING) {
+    OnTouchEventAckForQueueFront(sequence.front().ack_state() ==
+                                 GestureEventDataPacket::AckState::CONSUMED);
+  }
+}
+
+void TouchDispositionGestureFilter::OnTouchEventAckForQueueBack(
+    bool event_consumed) {

[jdduke (slow), 2014/11/25 16:21:35]

Hmm, but |event_consumed| should always be true, no? Otherwise we'll get
out-of-order gestures. So really this API should be phrased in terms of
dropping/ignoring the last touch or queue back.

[tdresser, 2014/11/25 20:07:49]

How could this result in out-of-order gestures? The events in the
TouchDispositionGestureFilter are never dispatched out of order.

I think this is a clearer design. For instance, in
WindowEventDispatcher::PostDispatchEvent, it's nice to be able to call
AckSyncTouchEvent indicating that the touch is not consumed. I think this is
clearer even if in this context AckSyncTouchEvent and AckAsyncTouchEvent would
always do the same thing, which I'm not completely convinced is the case.

I'm not 100% positive that we don't have cases where we alternate between async
and sync acks where some of the sync acks are "unconsumed." For example, can
|host_->ShouldForwardTouchEvent()| in RenderWidgetHostViewAura change during a
touch sequence? That could result in us switching between async and sync acks.

Being robust enough to handle arbitrary orderings of async and sync acks feels
like it's just as clear a design, and is less prone to falling down in edge
cases we haven't thought of.

[jdduke (slow), 2014/11/25 20:11:30]

Nevermind, you're right, the dispatch is deferred.

+  DCHECK(!Tail().empty());
+  if (Tail().size() == 1)
+    OnTouchEventAckForQueueFront(event_consumed);
+  else
+    Tail().back().ack(event_consumed);
 }
 
 bool TouchDispositionGestureFilter::IsEmpty() const {