Move compositor InputHandler from RenderViewImpl to RenderWidget.

cc/trees/layer_tree_host_impl.cc

 // 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.
 
 #include "cc/trees/layer_tree_host_impl.h"
 
 #include <stddef.h>
 #include <stdint.h>
 
 #include <algorithm>
@@ skipping 598 matching lines @@
 LayerTreeHostImpl::EventListenerTypeForTouchStartAt(
     const gfx::Point& viewport_point) {
   gfx::PointF device_viewport_point = gfx::ScalePoint(
       gfx::PointF(viewport_point), active_tree_->device_scale_factor());
 
   // Now determine if there are actually any handlers at that point.
   // TODO(rbyers): Consider also honoring touch-action (crbug.com/347272).
   LayerImpl* layer_impl =
       active_tree_->FindLayerThatIsHitByPointInTouchHandlerRegion(
           device_viewport_point);
-  if (layer_impl == NULL)
+  if (layer_impl == NULL) {

[enne (OOO), 2017/01/18 01:41:53]

I worry a bit about the side effects of always considering not finding a layer
to be considered finding something.

How is there no layer tree in this case?

[wjmaclean, 2017/01/18 02:14:10]

That's not quite what this CL is doing. The call to eventListenerProperties is
what tells us there is (or isn't) something, but due to the lack of
touch-handler rects from ScrollingCoordinator, which doesn't know how to deal
with OOPIFs, this approach just loses the fine-grained targeting. It seems safer
to indicate there's a handler (since there is) and force the event handling onto
the main thread, than drop an event that truly has a handler.
OOPIFs have a weird compositor setup. Prior to this CL, each local-root subframe
in an OOPIF renderer gets it's own layer tree to draw it. The RenderView also
gets a LayerTree, but it never draws anything since the main frame is remote to
the OOPIF renderer. But up until now, all the event listener properties have
been shoved onto the RenderView's LayerTree (meaning we can't tell which
particular subframe has a handler if only one of them does).

Up until this CL, *all* events sent to an OOPIF subframe have therefore been
forced onto the main thread, and thus OOPIFs have no ability to do things like
composited scrolling. Actually, to be more accurate, until this CL non of the
subframe LayerTrees have had InputHandlers, thus their events defaulted to the
main thread.

[enne (OOO), 2017/01/18 19:11:44]

You say that the side effects aren't a worry because this is behind a flag, but
this code looks to me like it says that for all touch handling queries, if it
doesn't hit a layer then pretend like it does.  There's nothing oopif specific
here, unless I'm really misreading this.

I apologize for all the confusion, but I still don't quite fully understand what
you're trying to do.  Is there not a way to specify a touch region that covers
everything so that the cc input handling code doesn't have to special case this?
Are events being forced on the main thread or are events being dropped? You say
both, so I'm a little confused what the previous behavior is.

Is there a design doc or something else to read for more context here?

+    // At present, TouchHandlerRegions are only set for LayerTrees serving the
+    // document's mainframe, i.e. LayerTrees that have a ViewPort defined. But
+    // subframes can still have touch handlers, so here we err on the side of
+    // caution and report a handler even if we don't know which layer it's on.
+    EventListenerProperties properties =
+        active_tree_->event_listener_properties(
+            EventListenerClass::kTouchStartOrMove);
+    if ((properties == EventListenerProperties::kBlocking ||
+         properties == EventListenerProperties::kBlockingAndPassive) &&
+        !active_tree_->OuterViewportScrollLayer()) {
+      return InputHandler::TouchStartEventListenerType::HANDLER;
+    }
     return InputHandler::TouchStartEventListenerType::NO_HANDLER;
+  }
 
   if (!CurrentlyScrollingLayer())
     return InputHandler::TouchStartEventListenerType::HANDLER;
 
   bool is_ancestor =
       IsScrolledBy(layer_impl, active_tree_->CurrentlyScrollingLayer());
   return is_ancestor ? InputHandler::TouchStartEventListenerType::
                            HANDLER_ON_SCROLLING_LAYER
                      : InputHandler::TouchStartEventListenerType::HANDLER;
 }
@@ skipping 2357 matching lines @@
   bool is_viewport_scroll_layer =
       viewport()->MainScrollLayer() &&
       scroll_node->owning_layer_id == viewport()->MainScrollLayer()->id();
 
   // This is needed if the scroll chains up to the viewport without going
   // through the outer viewport scroll layer. This can happen if we scroll an
   // element that's not a descendant of the document.rootScroller. In that case
   // we want to scroll the inner viewport -- to allow panning while zoomed --
   // but also move browser controls if needed.
   bool is_inner_viewport_scroll_layer =
+      InnerViewportScrollLayer() &&
       scroll_node->owning_layer_id == InnerViewportScrollLayer()->id();
 
   if (is_viewport_scroll_layer || is_inner_viewport_scroll_layer) {
     Viewport::ScrollResult result = viewport()->ScrollBy(
         delta, viewport_point, scroll_state->is_direct_manipulation(),
         !wheel_scrolling_, is_viewport_scroll_layer);
 
     applied_delta = result.consumed_delta;
     delta_applied_to_content = result.content_scrolled_delta;
   } else {
@@ skipping 1084 matching lines @@
       worker_context_visibility_ =
           worker_context->CacheController()->ClientBecameVisible();
     } else {
       worker_context->CacheController()->ClientBecameNotVisible(
           std::move(worker_context_visibility_));
     }
   }
 }
 
 }  // namespace cc