Touch event flag should control only DOM event firing.

chrome/browser/about_flags.cc

Index: chrome/browser/about_flags.cc
diff --git a/chrome/browser/about_flags.cc b/chrome/browser/about_flags.cc
index 8a9cd158aae08062c29d92c346c56ea802ff378d..cf144a807d3c60a198191ab7ab2aa4a0d508ef04 100644
--- a/chrome/browser/about_flags.cc
+++ b/chrome/browser/about_flags.cc
@@ -135,13 +135,11 @@ const unsigned kOsAll = kOsMac | kOsWin | kOsLinux | kOsCrOS | kOsAndroid;
 const unsigned kOsDesktop = kOsMac | kOsWin | kOsLinux | kOsCrOS;
 
 const FeatureEntry::Choice kTouchEventsChoices[] = {
-  { IDS_GENERIC_EXPERIMENT_CHOICE_AUTOMATIC, "", "" },
-  { IDS_GENERIC_EXPERIMENT_CHOICE_ENABLED,
-    switches::kTouchEvents,
-    switches::kTouchEventsEnabled },
-  { IDS_GENERIC_EXPERIMENT_CHOICE_DISABLED,
-    switches::kTouchEvents,
-    switches::kTouchEventsDisabled }
+    { IDS_GENERIC_EXPERIMENT_CHOICE_ENABLED, "", "" },

[Rick Byers, 2016/11/24 23:53:06]

Does this mean that "enabled" is now the default, instead of "auto" (determined
based on the presence of a touchscreen)?  That's going to be a problem for web
compat due to http://crbug.com/392584.  Basically there are still a bunch of
websites on which mouse support is broken when the TouchEvents API is present. 
So IMHO we need to retain this hacky "auto" behavior as the default for the
touch event API status.

The rest of the patch looks great though - thanks especially for the renames /
clarifications!

+    { IDS_GENERIC_EXPERIMENT_CHOICE_DISABLED, switches::kTouchEvents,
+        switches::kTouchEventsDisabled },
+    { IDS_GENERIC_EXPERIMENT_CHOICE_AUTOMATIC, switches::kTouchEvents,
+        switches::kTouchEventsAuto }
 };
 
 #if defined(USE_AURA)