Turn on AreCrossProcessFramesPossible by default.

content/browser/renderer_host/render_widget_host_view_event_handler.cc

Index: content/browser/renderer_host/render_widget_host_view_event_handler.cc
diff --git a/content/browser/renderer_host/render_widget_host_view_event_handler.cc b/content/browser/renderer_host/render_widget_host_view_event_handler.cc
index 2307c54ea031f41d6084be4746e431d84f305814..17f605df0cc5658f23d03ae55a2dc89005e8d316 100644
--- a/content/browser/renderer_host/render_widget_host_view_event_handler.cc
+++ b/content/browser/renderer_host/render_widget_host_view_event_handler.cc
@@ -840,6 +840,7 @@ bool RenderWidgetHostViewEventHandler::ShouldRouteEvent(
                 !disable_input_event_router_for_testing_;
   // ScrollEvents get transformed into MouseWheel events, and so are treated
   // the same as mouse events for routing purposes.
+  // TODO(creis): Is this right?

[wjmaclean, 2017/02/03 17:01:53]

Yes, I think this is correct. (Although these days I think the mouse-wheels get
converted to GestureScrolls, and not the other way around).

We should start to look at the cases where there is no delegate, or the delegate
has no input event router, and see if they still exist.

There's already a bug filed to make |disable_input_event_router_for_testing_|
unnecessary.

[Charlie Reis, 2017/02/13 22:02:49]

Acknowledged.

   if (event->IsMouseEvent() || event->type() == ui::ET_SCROLL)
     result = result && SiteIsolationPolicy::AreCrossProcessFramesPossible();
   return result;