Add initial CC support for scroll-blocks-on

cc/input/input_handler.h

 // Copyright 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CC_INPUT_INPUT_HANDLER_H_
 #define CC_INPUT_INPUT_HANDLER_H_
 
 #include "base/basictypes.h"
 #include "base/memory/scoped_ptr.h"
 #include "base/time/time.h"
@@ skipping 124 matching lines @@
                                   const gfx::Point& anchor) = 0;
   virtual void PinchGestureEnd() = 0;
 
   // Request another callback to InputHandlerClient::Animate().
   virtual void SetNeedsAnimate() = 0;
 
   // Whether the layer under |viewport_point| is the currently scrolling layer.
   virtual bool IsCurrentlyScrollingLayerAt(const gfx::Point& viewport_point,
                                            ScrollInputType type) = 0;
 
   virtual bool HaveWheelEventHandlersAt(const gfx::Point& viewport_point) = 0;

[jdduke (slow), 2015/02/03 16:43:34]

Now that "blocks on" is the phrasing used for both wheel events and touch
events, is there a reason to have different names for the two queries
(HaveWheelEventHandlersAt vs DoTouchEventsBlockScrollAt)? I guess the semantics
are slightly different, but I wonder if there's a consistent naming scheme here
that communicates just the necessary bits, e.g.,

|ShouldForwardTouchToMain|
|ShouldForwardWheelToMain|

or something like that? Not a huge deal though.

[Rick Byers, 2015/02/05 04:35:53]

Yeah I considered changing this but the semantics are different.  In particular
HaveWheelEventHandlersAt returns ONLY if there are wheel event handlers
(scroll-blocks-on handling is handled outside).  DoTouchEventBlockScrollAt looks
at both touch handler rects and the scroll-blocks-on mode.  The reason for the
difference is just the different places these are used -
HaveWheelEventHandlersAt is part of the scrolling system (which already looks at
scroll-blocks-on), but DoTouchEventsBlockScroll is used more in isolation to
decide when to forward touch events to blink.  So I think the asymmetry reflects
a real difference - it's now misleading to think of these as the same thing.

But I only spent a few minutes looking for ways to refactor things to be more
symmetric.  I'm open to suggestions.

-  virtual bool HaveTouchEventHandlersAt(const gfx::Point& viewport_point) = 0;
+
+  // Whether the page should be given the opportunity to suppress scrolling by
+  // consuming touch events that started at |viewport_point|.
+  virtual bool DoTouchEventsBlockScrollAt(const gfx::Point& viewport_point) = 0;
 
   // Calling CreateLatencyInfoSwapPromiseMonitor() to get a scoped
   // LatencyInfoSwapPromiseMonitor. During the life time of the
   // LatencyInfoSwapPromiseMonitor, if SetNeedsRedraw() or SetNeedsRedrawRect()
   // is called on LayerTreeHostImpl, the original latency info will be turned
   // into a LatencyInfoSwapPromise.
   virtual scoped_ptr<SwapPromiseMonitor> CreateLatencyInfoSwapPromiseMonitor(
       ui::LatencyInfo* latency) = 0;
 
   virtual ScrollElasticityHelper* CreateScrollElasticityHelper() = 0;
 
  protected:
   InputHandler() {}
   virtual ~InputHandler() {}
 
  private:
   DISALLOW_COPY_AND_ASSIGN(InputHandler);
 };
 
 }  // namespace cc
 
 #endif  // CC_INPUT_INPUT_HANDLER_H_