Route touch-events for WebViewGuest directly to guest renderer.

content/browser/web_contents/web_contents_impl.cc

 // Copyright (c) 2012 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 "content/browser/web_contents/web_contents_impl.h"
 
 #include <utility>
 
 #include "base/command_line.h"
 #include "base/lazy_instance.h"
@@ skipping 1586 matching lines @@
 #endif
   return false;
 }
 
 bool WebContentsImpl::PreHandleGestureEvent(
     const blink::WebGestureEvent& event) {
   return delegate_ && delegate_->PreHandleGestureEvent(this, event);
 }
 
 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();
 }
 
 void WebContentsImpl::ReplicatePageFocus(bool is_focused) {
   // Focus loss may occur while this WebContents is being destroyed.  Don't
   // send the message in this case, as the main frame's RenderFrameHost and
   // other state has already been cleared.
   if (is_being_destroyed_)
     return;
 
@@ skipping 3182 matching lines @@
   return NULL;
 }
 
 void WebContentsImpl::SetForceDisableOverscrollContent(bool force_disable) {
   force_disable_overscroll_content_ = force_disable;
   if (view_)
     view_->SetOverscrollControllerEnabled(CanOverscrollContent());
 }
 
 }  // namespace content