[Android] Ensure slop-exceeding TouchMove's are sent to the renderer

content/browser/renderer_host/input/touch_event_queue.cc

Index: content/browser/renderer_host/input/touch_event_queue.cc
diff --git a/content/browser/renderer_host/input/touch_event_queue.cc b/content/browser/renderer_host/input/touch_event_queue.cc
index 9924c903a26318e2d91e177f8ded5cf83e9b1a60..5c24d3843a43ca614784d82b6dda6eb44f76f432 100644
--- a/content/browser/renderer_host/input/touch_event_queue.cc
+++ b/content/browser/renderer_host/input/touch_event_queue.cc
@@ -176,9 +176,11 @@ class TouchEventQueue::TouchTimeoutHandler {
 // a given slop region, unless the touchstart is preventDefault'ed.
 class TouchEventQueue::TouchMoveSlopSuppressor {
  public:
+  // TODO(jdduke): Remove int cast on suppression length, crbug.com/3336807.

[tdresser, 2014/02/21 21:44:50]

No such bug?

[jdduke (slow), 2014/02/21 22:29:05]

Oops, good catch.

   TouchMoveSlopSuppressor(double slop_suppression_length_dips)
-      : slop_suppression_length_dips_squared_(slop_suppression_length_dips *
-                                              slop_suppression_length_dips),
+      : slop_suppression_length_dips_squared_(
+            static_cast<int>(slop_suppression_length_dips) *
+            static_cast<int>(slop_suppression_length_dips)),
         suppressing_touch_moves_(false) {}
 
   bool FilterEvent(const WebTouchEvent& event) {
@@ -197,8 +199,10 @@ class TouchEventQueue::TouchMoveSlopSuppressor {
         suppressing_touch_moves_ = false;
       } else if (event.touchesLength == 1) {
         // Movement outside of the slop region should terminate suppression.
-        gfx::PointF position = gfx::Point(event.touches[0].position);
-        if ((position - touch_sequence_start_position_).LengthSquared() >
+        // TODO(jdduke): Use strict inequality, crbug.com/3336807.
+        gfx::PointF position(event.touches[0].position.x,
+                             event.touches[0].position.y);
+        if ((position - touch_sequence_start_position_).LengthSquared() >=

[Rick Byers, 2014/02/21 20:22:49]

In my Aura fix I was trying to keep the strict inequality, but if we're willing
to increase the occurrence of multiple touchmoves than this is definitely
simpler (and probably solves the problem for Aura and Android with the same CL).
 We can wait for the unified GR to put this back to a strict inequality.

When there is more than one touchmove event before scrolling starts, how are the
dispositions handled?  Does consuming ANY of them prevent scrolling in both Aura
and Android?  If so (or at least if consuming the _first_ is guaranteed to
prevent scrolling) then I think this should be fine for 34.  In 35 hopefully
we'll have touch move absorption and this will be different (there is the
disposition of only the first that's really special - as required by the
TouchEvent spec).

[tdresser, 2014/02/21 21:44:50]

Consuming any touch move will prevent scrolling. (See
https://code.google.com/p/chromium/issues/detail?id=333947 for the Aura bug on
this).

[jdduke (slow), 2014/02/21 22:29:05]

Yeah, with unified GR we can toggle the inequality quite easily.  

For now, the non strict inequality here means Android could potentially send
multiple touchmove's before the sequence turns into a scroll, but this will be
relatively infrequent.  There's really no way around this with integer DIP
coords.  In any case, it's better than occasionally never offering the touchmove
at all, and we can certainly tighten this up for M35.

                 slop_suppression_length_dips_squared_)
           suppressing_touch_moves_ = false;
       }