Stop negating the overscroll velocity to enable the glow of main thread fling

content/renderer/input/render_widget_input_handler.cc

Index: content/renderer/input/render_widget_input_handler.cc
diff --git a/content/renderer/input/render_widget_input_handler.cc b/content/renderer/input/render_widget_input_handler.cc
index 3ea242a1e554f38c8684921c04c07fb6751961eb..a67366787b0c4702064c1246526b4c395e274aec 100644
--- a/content/renderer/input/render_widget_input_handler.cc
+++ b/content/renderer/input/render_widget_input_handler.cc
@@ -517,7 +517,7 @@ void RenderWidgetInputHandler::DidOverscrollFromBlink(
   // TODO(sataya.m): don't negate velocity once http://crbug.com/499743 is

[dtapuska, 2016/08/29 21:16:34]

Do we need to remove this comment? Is this partially fixed now?

[majidvp, 2016/08/31 19:39:40]

Overscroll glow logic expects to receive delta and velocity of scroll which are
in the same direction.

In the past this velocity here was the actual *gesture* velocity which needed to
be negated to get scroll behaviour. I did some digging and I think this bokan@
changed the semantic of this velocity here which is probably the point where the
glow effect broke: https://codereview.chromium.org/1755773002

So yes, please remove this TODO and close that bug as well :).

[bokan, 2016/08/31 21:04:30]

Yes, I believe that's correct.

   // fixed.
   params->current_fling_velocity =
-      gfx::Vector2dF(-velocity.width, -velocity.height);
+      gfx::Vector2dF(velocity.width, velocity.height);
   params->causal_event_viewport_point = gfx::PointF(position.x, position.y);
 
   // If we're currently handling an event, stash the overscroll data such that