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

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 1572 matching lines @@
 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;
 
   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.
   RenderWidgetHostView* const widget_view = GetFullscreenRenderWidgetHostView();
   if (widget_view)
     RenderWidgetHostImpl::From(widget_view->GetRenderWidgetHost())->Shutdown();
 
   if (delegate_)
     delegate_->EnterFullscreenModeForTab(this, origin);
 
@@ skipping 3047 matching lines @@
   return NULL;
 }
 
 void WebContentsImpl::SetForceDisableOverscrollContent(bool force_disable) {
   force_disable_overscroll_content_ = force_disable;
   if (view_)
     view_->SetOverscrollControllerEnabled(CanOverscrollContent());
 }
 
 }  // namespace content