Reset the default value of touch event flag back to "Auto".

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 715b6d402ca01e469a5210943b55e5826c231707..1654c6873eaf6d9aec0cb782c6cf2a19cb79ca7c 100644
--- a/third_party/WebKit/Source/core/input/TouchEventManager.cpp
+++ b/third_party/WebKit/Source/core/input/TouchEventManager.cpp
@@ -18,7 +18,6 @@
 #include "core/page/Page.h"
 #include "platform/Histogram.h"
 #include "platform/PlatformTouchEvent.h"
-#include "platform/RuntimeEnabledFeatures.h"
 #include "wtf/CurrentTime.h"
 #include "wtf/PtrUtil.h"
 #include <memory>
@@ -490,8 +489,9 @@ class CurrentEventHolder {
 WebInputEventResult TouchEventManager::handleTouchEvent(
     const PlatformTouchEvent& event,
     HeapVector<TouchInfo>& touchInfos) {
-  if (!RuntimeEnabledFeatures::touchEventAPIEnabled())
-    return WebInputEventResult::HandledSuppressed;
+  // We ideally want to suppress TouchEvent firing when touch detection is

[Rick Byers, 2016/12/01 21:40:16]

FWIW I don't agree with this comment.  We'd "ideally" send touch events all the
time AND enable TouchEvent feature detection all the time.  But the latter has
stupid web compat problems, so we can't do it.  But IMHO there's no good reason
not to do the former.

Perhaps we should rename (again, sorry) the feature from "touchEventAPIEnabled"
to "touchEventFeatureDetectionEnabled"?  Or for now just add a comment to
RuntimeEnabledFeatures.in saying that's really what it means (that "touch
events" themselves are always enabled since they're a feature always supported
by Chrome).

+  // disabled but we need to support dev-tools emulation and "some" dynamic
+  // cases.
 
   // Track the current event for the scope of this function.
   CurrentEventHolder holder(m_currentEvent, event.type());