Don't send touch move to renderer while scrolling

content/browser/renderer_host/render_widget_host_impl.cc

Index: content/browser/renderer_host/render_widget_host_impl.cc
diff --git a/content/browser/renderer_host/render_widget_host_impl.cc b/content/browser/renderer_host/render_widget_host_impl.cc
index dae48644401620fd85acc828cfd81647504de6f8..8fe4150955c4447e4523cd3f6bbfa21c7659df8e 100644
--- a/content/browser/renderer_host/render_widget_host_impl.cc
+++ b/content/browser/renderer_host/render_widget_host_impl.cc
@@ -169,6 +169,7 @@ RenderWidgetHostImpl::RenderWidgetHostImpl(RenderWidgetHostDelegate* delegate,
       suppress_next_char_events_(false),
       pending_mouse_lock_request_(false),
       allow_privileged_mouse_lock_(false),
+      scroll_update_in_progress_(false),
       has_touch_handler_(false),
       weak_factory_(this),
       touch_event_queue_(new TouchEventQueue(this)),
@@ -1064,6 +1065,24 @@ void RenderWidgetHostImpl::ForwardGestureEvent(
   if (ignore_input_events_ || process_->IgnoreInputEvents())
     return;
 
+  if (CommandLine::ForCurrentProcess()->GetSwitchValueASCII(
+          switches::kTouchCancelOnScroll) == "1") {
+    // When there is touch handler on the page, once scrolling is started,
+    // we send a touch cancel to the page, and stops forwarding touch events to
+    // the renderer. This is to align with Chrome on Android behavior.
+    if (gesture_event.type == WebInputEvent::GestureScrollUpdate &&

[sadrul, 2013/06/20 08:51:27]

You should do this on GestureScrollBegin event, which marks the beginning of the
scroll. So the touch-cancel should go to the renderer before the scrolling
starts.

[Yufeng Shen (Slow to review), 2013/06/20 17:56:45]

I have a comment in the description of the CL about why using
GestureScrollUpdate
instead of GestureScrollBegin.

Mainly it is for the 2 finger case. With current implementation of gesture
recognizer, if touch move is prevented default, and we use 2 fingers scroll, we
can still generate GestureScrollBegin (but not GestureScrollUpdate). And if we
send cancel on GestureScrollBegin, it is wrong since the page wants to consume
touch move.

+        ShouldForwardTouchEvent() &&
+        !scroll_update_in_progress_) {
+      scroll_update_in_progress_ = true;
+      touch_event_queue_->OnGestureScrollStart();
+    }
+
+    if (gesture_event.type == WebInputEvent::GestureScrollEnd ||
+        gesture_event.type == WebInputEvent::GestureFlingStart) {
+      scroll_update_in_progress_ = false;
+    }
+  }
+
   ui::LatencyInfo latency_info = NewInputLatencyInfo();
 
   if (!IsInOverscrollGesture() &&
@@ -2287,11 +2306,15 @@ const gfx::Vector2d& RenderWidgetHostImpl::GetLastScrollOffset() const {
 }
 
 bool RenderWidgetHostImpl::ShouldForwardTouchEvent() const {
+  // 1. Scroll update is in progress:
+  // Don't send any touch events to the renderer.
+  // 2. Scroll update is not in progress:
   // Always send a touch event if the renderer has a touch-event handler. It is
   // possible that a renderer stops listening to touch-events while there are
   // still events in the touch-queue. In such cases, the new events should still
   // get into the queue.
-  return has_touch_handler_ || !touch_event_queue_->empty();
+  return (has_touch_handler_ || !touch_event_queue_->empty()) &&
+      !scroll_update_in_progress_;

[sadrul, 2013/06/20 08:51:27]

Can you expose gesture_event_filter_->scrolling_in_progress(), and use that here
instead of maintaining the same state here in RWHI?

[Yufeng Shen (Slow to review), 2013/06/20 17:56:45]

gesture_event_filter->scrolling_in_progress_  is designed for debouncing purpose
and it has the feature that if it is set on GestureScrollUpdate, but not renewed
in debounce_interval_time_ms_, the debounce_deferring_timer callback will clear
it, that means if we scroll slowly, there would be

GestureScrollUpdate
-> scrolling_in_progress_ = true
-> 30ms later scrolling_in_progress_ = false
-> touch events are sent to renderer (wrong!)
-> new GestureScrollUpdate arrives
-> scrolling_in_progress_ = true

So it does not quite carry the semantics of the scroll_update_in_progress_ we 
maintain in RWHI.

 }
 
 void RenderWidgetHostImpl::StartUserGesture() {