Mark touchcancel events as uncancelable

content/browser/renderer_host/input/touch_event_queue.cc

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/renderer_host/input/touch_event_queue.h"
 
 #include "base/auto_reset.h"
 #include "base/command_line.h"
 #include "base/debug/trace_event.h"
 #include "base/stl_util.h"
 #include "content/browser/renderer_host/input/timeout_monitor.h"
-#include "content/browser/renderer_host/input/web_touch_event_traits.h"
+#include "content/common/input/web_touch_event_traits.h"
 #include "content/public/common/content_switches.h"
 #include "ui/gfx/geometry/point_f.h"
 
 using blink::WebInputEvent;
 using blink::WebTouchEvent;
 using blink::WebTouchPoint;
 using ui::LatencyInfo;
 
 namespace content {
 namespace {
 
 // Using a small epsilon when comparing slop distances allows pixel perfect
 // slop determination when using fractional DIP coordinates (assuming the slop
 // region and DPI scale are reasonably proportioned).
 const float kSlopEpsilon = .05f;
 
 typedef std::vector<TouchEventWithLatencyInfo> WebTouchEventWithLatencyList;
 
 TouchEventWithLatencyInfo ObtainCancelEventForTouchEvent(
     const TouchEventWithLatencyInfo& event_to_cancel) {
   TouchEventWithLatencyInfo event = event_to_cancel;
-  event.event.type = WebInputEvent::TouchCancel;
-  for (size_t i = 0; i < event.event.touchesLength; i++)
-    event.event.touches[i].state = WebTouchPoint::StateCancelled;
+  WebTouchEventTraits::ResetType(&event.event,
+                                 WebInputEvent::TouchCancel,
+                                 // FIXME: Shouldn't we use a fresh timestamp?
+                                 event.event.timeStampSeconds,

[jdduke (slow), 2014/04/23 21:55:47]

Nah, I don't think it matters at this point.

[Rick Byers, 2014/04/23 23:15:35]

Why?  Shouldn't an app be able to see that a timeout touchcancel is always
generated ~150ms after the previous touch event?  Also I think apps may expect
touch events to arrive in monotonically increasing timeout value (eg. don't
expect a negative delta from one to the next). 

[jdduke (slow), 2014/04/23 23:29:49]

I think we're monotonically non-decreasing, and I see your point about the
timestamps.  Doesn't blink end up over-writing all of the provided timestamps
anyway? I guess that's still not a good reason to lie here... The FIXME is fine
:)

+                                 WebTouchEventTraits::RESET_TOUCHES_STATE);
   return event;
 }
 
 bool ShouldTouchTypeTriggerTimeout(WebInputEvent::Type type) {
   return type == WebInputEvent::TouchStart ||
          type == WebInputEvent::TouchMove;
 }
 
 }  // namespace
 
@@ skipping 588 matching lines @@
   } else if (event.type == WebInputEvent::TouchStart) {
     for (unsigned i = 0; i < event.touchesLength; ++i) {
       const WebTouchPoint& point = event.touches[i];
       if (point.state == WebTouchPoint::StatePressed)
         touch_ack_states_[point.id] = ack_result;
     }
   }
 }
 
 }  // namespace content