Allow postponed rail application for touch scrolling - blink side.

public/web/WebInputEvent.h

Index: public/web/WebInputEvent.h
diff --git a/public/web/WebInputEvent.h b/public/web/WebInputEvent.h
index d212f6fe2a2a0e21cde6fe3a232b960849b1cad0..096b41476a5112a18b9d76fd2a78852a852c9dc0 100644
--- a/public/web/WebInputEvent.h
+++ b/public/web/WebInputEvent.h
@@ -173,7 +173,7 @@ public:
         IsRight          = 1 << 12,
     };
 
-    // The rail mode for a wheel event specifies the axis on which scrolling is
+    // The rail mode for an event specifies the axis on which scrolling is
     // expected to stick. If this axis is set to Free, then scrolling is not
     // stuck to any axis.
     enum RailsMode {
@@ -480,11 +480,13 @@ public:
             bool previousUpdateInSequencePrevented;
             bool preventPropagation;
             bool inertial;
+            RailsMode railsMode;

[jdduke (slow), 2015/04/02 16:55:53]

I can't say I'm thrilled with this change. Now, every handler of any kind of
scroll event will have to monitor the rails mode and make the right call (e.g.,
looking at the rails definition to make sure RailsModeHorizontal means snap to
the x-axis, not truncate the x-axis). We're effectively placing the burden on
the common case to support the exceptional case (JS-based scroll customization).

For me the ideal would be to bundle the "filtered" values, as they are now, with
the unfiltered or raw values, then have some bit flags that indicate what kind
of filters was applied, e.g., rails, or slop removal, to map the raw to the
actual. Maybe that's naive, but it makes it a lot more difficult to get things
wrong, and I can think of 7 or 8 places off the top of my head where this change
will break behavior in Chrome.

         } scrollUpdate;
 
         struct {
             float velocityX;
             float velocityY;
+            RailsMode railsMode;
         } flingStart;
 
         struct {