Allow postponed rail application for touch scrolling - blink side.

public/web/WebInputEvent.h

 /*
  * Copyright (C) 2009 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 155 matching lines @@
         // into WebCore, so round-tripping from WebInputEvent to a WebCore
         // event and back will not preserve these flags.
         CapsLockOn       = 1 << 9,
         NumLockOn        = 1 << 10,
 
         // Left/right modifiers for keyboard events.
         IsLeft           = 1 << 11,
         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 {
         RailsModeFree       = 0,
         RailsModeHorizontal = 1,
         RailsModeVertical   = 2,
     };
 
     static const int InputModifiers = ShiftKey | ControlKey | AltKey | MetaKey;
 
@@ skipping 286 matching lines @@
             float velocityX;
             float velocityY;
             // Whether any previous GestureScrollUpdate in the current scroll
             // sequence was suppressed (e.g., the causal touchmove was
             // preventDefault'ed). This bit is particularly useful for
             // determining whether the observed scroll update sequence captures
             // the entirety of the generative motion.
             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 {
             // If set to true, don't treat flingCancel
             // as a part of fling boost events sequence.
             bool preventBoosting;
         } flingCancel;
 
         struct {
             float scale;
@@ skipping 45 matching lines @@
         , uniqueTouchEventId(0)
     {
     }
 };
 
 #pragma pack(pop)
 
 } // namespace blink
 
 #endif