Chrome requires WebTouchPoint to store WebFloatPoint, instead of WebPoint.

content/renderer/input/input_handler_proxy.cc

Index: content/renderer/input/input_handler_proxy.cc
diff --git a/content/renderer/input/input_handler_proxy.cc b/content/renderer/input/input_handler_proxy.cc
index 7a66730c4f43d9c7a28f137ba001b7b4f8a804c1..d39024df67bf893286c2b93cb5974a6282791e95 100644
--- a/content/renderer/input/input_handler_proxy.cc
+++ b/content/renderer/input/input_handler_proxy.cc
@@ -13,6 +13,7 @@
 #include "third_party/WebKit/public/web/WebInputEvent.h"
 #include "ui/events/latency_info.h"
 #include "ui/gfx/frame_time.h"
+#include "ui/gfx/geometry/point_conversions.h"
 
 using blink::WebFloatPoint;
 using blink::WebFloatSize;
@@ -231,8 +232,7 @@ InputHandlerProxy::EventDisposition InputHandlerProxy::HandleInputEvent(
       if (touch_event.touches[i].state != WebTouchPoint::StatePressed)
         continue;
       if (input_handler_->HaveTouchEventHandlersAt(
-              blink::WebPoint(touch_event.touches[i].position.x,
-                              touch_event.touches[i].position.y))) {
+              gfx::ToFlooredPoint(touch_event.touches[i].position))) {

[jdduke (slow), 2014/03/20 12:11:34]

Hmm, this may be a small change in behavior.  Previously, the coords were
truncated, but now they're being floored, no?  Can we just use gfx::Point()
constructor here, and eventually we should update the method to take a
gfx::PointF.

[tdresser, 2014/03/20 14:09:14]

Done. 

I'm not convinced it really makes sense to make HaveTouchEventHandlersAt take a
gfx::PointF. Patch #4 did this, but I couldn't see much benefit. Why do you
think it would be preferable?

         return DID_NOT_HANDLE;
       }
     }