Implement Wheel Gesture Scrolling on OSX.

ui/events/blink/input_scroll_elasticity_controller.h

Index: ui/events/blink/input_scroll_elasticity_controller.h
diff --git a/ui/events/blink/input_scroll_elasticity_controller.h b/ui/events/blink/input_scroll_elasticity_controller.h
index 8c6468109c8e6df47efbf2565493b6c6999dfc5b..915b2e88af12cd7ee2e5a492e3a7f000f3f0c539 100644
--- a/ui/events/blink/input_scroll_elasticity_controller.h
+++ b/ui/events/blink/input_scroll_elasticity_controller.h
@@ -58,6 +58,15 @@ class InputScrollElasticityController {
   void ObserveWheelEventAndResult(
       const blink::WebMouseWheelEvent& wheel_event,
       const cc::InputHandlerScrollResult& scroll_result);
+  // Update the overscroll state based a gesture event that has been processed.
+  // Note that this assumes that all events are coming from a single input
+  // device. If the user simultaneously uses multiple input devices, Cocoa may
+  // not correctly pass all the gesture begin and end events. In this case,
+  // this class may disregard some scrolls that come in at unexpected times.

[tdresser, 2016/03/08 14:28:53]

How hard would it be to have a test of this behavior, ensuring that things don't
explode? I guess we'd have to characterize the unreliable Cocoa behavior, which
probably isn't worth it?

[dtapuska, 2016/03/08 20:31:49]

I think the behavior is that if you are using two input devices the phase
information will be interleaved and could be interpreted at incorrect times. The
mouse wheel event queue will try to make something sane out of it. But it could
certainly confused this class; this comment was copied from the
ObserveWheelEventAndResult because I feel it still applies. 

+  void ObserveGestureEventAndResult(
+      const blink::WebGestureEvent& gesture_event,
+      const cc::InputHandlerScrollResult& scroll_result);
+
   void Animate(base::TimeTicks time);
 
   void ReconcileStretchAndScroll();