Null-check GetView before using it in GetFocusedRenderWidgetHost.

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 1629 matching lines @@
 
   // Events for widgets other than the main frame (e.g., popup menus) should be
   // forwarded directly to the widget they arrived on.
   if (receiving_widget != GetMainFrame()->GetRenderWidgetHost())
     return receiving_widget;
 
   FrameTreeNode* focused_frame = frame_tree_.GetFocusedFrame();
   if (!focused_frame)
     return receiving_widget;
 
-  return RenderWidgetHostImpl::From(
-      focused_frame->current_frame_host()->GetView()->GetRenderWidgetHost());
+  // The view may be null if a subframe's renderer process has crashed while
+  // the subframe has focus.  Give the event to the main frame in this case.

[Charlie Reis, 2015/12/07 22:47:24]

Sanity check: What will the main frame do with it?  Will it recognize that none
of its frames had focus and thus do nothing with it?  Or will the event go to
something in the main frame?

I worry about a user typing something long into a subframe, and half of it
unexpectedly going into a different form in the main frame if the subframe
crashes while they're typing.

[alexmos, 2015/12/07 23:12:59]

That's a good point.  It's going to go to the main frame.  I've tried this out,
and if you start typing into field A on the main frame, then focus field B in a
subframe and start typing, and then crash the subframe renderer, keyboard input
from that point on will go into field A on the main frame.  I agree this
behavior would be unexpected/dangerous.  

I could return nullptr instead of the main frame here, though I'd need to also
update the three call sites for GetFocusedRWH to also do a null-check and drop
the event in this case.  Does this plan sound good?

[Charlie Reis, 2015/12/07 23:16:52]

Yes, let's do that.  Thanks!

[alexmos, 2015/12/07 23:21:50]

Done.  Please take a look.

+  RenderWidgetHostView* view = focused_frame->current_frame_host()->GetView();
+  if (!view)
+    return receiving_widget;
+
+  return RenderWidgetHostImpl::From(view->GetRenderWidgetHost());
 }
 
 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_)
@@ skipping 3144 matching lines @@
   return NULL;
 }
 
 void WebContentsImpl::SetForceDisableOverscrollContent(bool force_disable) {
   force_disable_overscroll_content_ = force_disable;
   if (view_)
     view_->SetOverscrollControllerEnabled(CanOverscrollContent());
 }
 
 }  // namespace content