Touchmoves should not be suppressed if the touchstart is consumed

third_party/WebKit/Source/core/input/TouchEventManager.cpp

Index: third_party/WebKit/Source/core/input/TouchEventManager.cpp
diff --git a/third_party/WebKit/Source/core/input/TouchEventManager.cpp b/third_party/WebKit/Source/core/input/TouchEventManager.cpp
index 149cff36bc908842d65b6dc63fe73d9b538f3a66..e97c665e0d10d25250f50a9cf9ae1a281fce515b 100644
--- a/third_party/WebKit/Source/core/input/TouchEventManager.cpp
+++ b/third_party/WebKit/Source/core/input/TouchEventManager.cpp
@@ -292,6 +292,13 @@ WebInputEventResult TouchEventManager::dispatchTouchEvents(
     }
   }
 
+  // Do not suppress any touchmoves if the touchstart is consumed.

[Rick Byers, 2017/02/16 21:21:57]

nit: it seems like it would be a small clean-up to move the
"m_suppressingTouchmovesWithinSlop = true;" line down from 131 into here.  I.e.
instead of setting it and then clearing it, we could just ONLY set it after a
touchstart has been dispatched that wasn't cancelled.

[mustaq, 2017/02/16 21:41:26]

The "true" value is used in Line 138, so we have to leave things up there
anyways I think.

[Rick Byers, 2017/02/16 22:09:19]

But it's used only if we're currently processing a TouchMove, and here we're
talking about setting it only after a TouchStart.  I.e. "am I suppressing slop
moves" is relevant between the time AFTER a the first touchstart has been
dispatched up until just BEFORE the last touchend/cancel has been dispatched. 
This bit doesn't really make sense DURING the dispatch of the first touchstart -
we don't actually know yet if we should be suppressing slop movement or not (and
it's irrelevant until we get the first move anyway).

[lanwei, 2017/02/17 15:11:17]

Acknowledged.
Yes, we can merge line 131 here, thank you.

+  if (m_suppressingTouchmovesWithinSlop &&
+      event.type() == WebInputEvent::TouchStart &&
+      eventResult != WebInputEventResult::NotHandled) {
+    m_suppressingTouchmovesWithinSlop = false;
+  }
+
   return eventResult;
 }