Route touch-events for WebViewGuest directly to guest renderer.

content/browser/web_contents/web_contents_impl.cc

Index: content/browser/web_contents/web_contents_impl.cc
diff --git a/content/browser/web_contents/web_contents_impl.cc b/content/browser/web_contents/web_contents_impl.cc
index c36e3a7772a42c2db4136b046e7e05f35b378305..3aa072282b7f9770d2e8447b22a22f474d220c92 100644
--- a/content/browser/web_contents/web_contents_impl.cc
+++ b/content/browser/web_contents/web_contents_impl.cc
@@ -1604,9 +1604,10 @@ bool WebContentsImpl::PreHandleGestureEvent(
 }
 
 RenderWidgetHostInputEventRouter* WebContentsImpl::GetInputEventRouter() {
-  // Currently only supported in site per process mode (--site-per-process).
-  if (!rwh_input_event_router_.get() && !is_being_destroyed_ &&
-      SiteIsolationPolicy::AreCrossProcessFramesPossible())
+  if (!is_being_destroyed_ && GetOuterWebContents())
+    return GetOuterWebContents()->GetInputEventRouter();
+
+  if (!rwh_input_event_router_.get() && !is_being_destroyed_)
     rwh_input_event_router_.reset(new RenderWidgetHostInputEventRouter);

[Charlie Reis, 2015/11/30 18:09:12]

Before this CL, we never created this in default Chrome, and now we always
create it (during RWHVAura's constructor).

There used to be a lot of code that checks for its existence (e.g., several
within RWHVAura), and even with your addition of ShouldRouteEvent it looks like
we'll be using the new path for touch events by default (not just in
BrowserPlugin).  Is this CL intended to affect all those cases?

[wjmaclean, 2015/12/10 16:09:07]

This CL is targeted to (in the short term) fixing touch events for
BrowserPlugin. However, it can be implemented generally since checks for the
existence of an IER are specific to (1) creation/destruction of RWHV{A|CF} or
(2) processing mouse/wheel/touch events, only the latter of which will have
effect without --site-per-process. Other view types, namely RWHVM and
RWHVAndroid, either do not yet make use of the IER (RWHVAndroid)  or don't use
it for touch (RWHVM).

[Charlie Reis, 2015/12/10 21:58:14]

This doesn't sound safe to me.

If I read this correctly, for case (1) we'll create an InputEventRouter for all
RenderWidgetHostViewAuras.  That affects desktop builds on Windows, Linux, and
ChromeOS, whether they have --site-per-process or guests or not.  That seems
like a behavior change to default Chrome on those platforms.

For case (2), the presence of an IER without --site-per-process will mean that
mouse/wheel/touch events will behave differently on Windows and Linux.

My earlier question is whether this behavior change is intended-- do those
events still work as well as before on Windows/Linux/ChromeOS without
--site-per-process?

   return rwh_input_event_router_.get();
 }