OOPIF: Route keyboard events to focused frame in the browser process.

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 6b1407b78e0ace939218a24a5478b0c23d48f1c3..f866c138d167035c173c9e997937244420004ce0 100644
--- a/content/browser/web_contents/web_contents_impl.cc
+++ b/content/browser/web_contents/web_contents_impl.cc
@@ -1590,6 +1590,18 @@ void WebContentsImpl::ReplicatePageFocus(bool is_focused) {
   frame_tree_.ReplicatePageFocus(is_focused);
 }
 
+RenderWidgetHostImpl* WebContentsImpl::GetFocusedRenderWidgetHost() {
+  if (!SiteIsolationPolicy::AreCrossProcessFramesPossible())
+    return GetMainFrame()->GetRenderWidgetHost();
+
+  FrameTreeNode* focused_frame = frame_tree_.GetFocusedFrame();
+  if (!focused_frame)
+    return GetMainFrame()->GetRenderWidgetHost();
+
+  return RenderWidgetHostImpl::From(
+      focused_frame->current_frame_host()->GetView()->GetRenderWidgetHost());

[Charlie Reis, 2015/10/29 18:14:02]

Ken, this is why I wanted RenderFrameHostImpl::GetRenderWidgetHost() to return
the widget associated with the current frame, and not nullptr in some cases.  We
end up with contortions like this, where we have to call
GetView()->GetRenderWidgetHost() and not GetRenderWidgetHost() directly.

I'll start a thread on site-isolation-dev@ to discuss this further.

[alexmos, 2015/10/29 22:22:08]

+1 to having GetRenderWidgetHost() return the widget for the current frame if
that's possible.

[kenrb, 2015/10/29 23:54:40]

We had discussed removing RenderFrameHostImpl::GetRenderWidgetHost() before,
since its usage appeared to be mostly in tests, on the basis that code that
doesn't already have a pointer to a RenderWidgetHostImpl should probably be
talking to the RenderWidgetHostView. I see that a couple more
GetRenderWidgetHost() calls have appeared since we had that discussion.

In this case, GetFocusedRenderWidgetHost() is being called by a
RenderWidgetHostView that already has a pointer to a RenderWidgetHost, but wants
a different one. If we ever want to add ChildFrame-specific code for handling
keyboard events, this method will need to change to
GetFocusedRenderWidgetHostView(), which would be simpler here but would mean a
new method getting added to RenderWidgetHostViewBase (similar to how mouse event
routing works).

I didn't think of this when I was looking at the CL earlier. It is fine, but
thanks for pointing it out. It is something we might want to revisit for sure.

+}
+
 void WebContentsImpl::EnterFullscreenMode(const GURL& origin) {
   // This method is being called to enter renderer-initiated fullscreen mode.
   // Make sure any existing fullscreen widget is shut down first.