Force MimeHandlerView to always use BrowserPlugin

content/browser/frame_host/render_widget_host_view_child_frame.cc

Index: content/browser/frame_host/render_widget_host_view_child_frame.cc
diff --git a/content/browser/frame_host/render_widget_host_view_child_frame.cc b/content/browser/frame_host/render_widget_host_view_child_frame.cc
index ed316e45611a80bd7fdb1c84c13a64e86d009e9d..7e5222d6eff4d121245773184e752b658b3d74ce 100644
--- a/content/browser/frame_host/render_widget_host_view_child_frame.cc
+++ b/content/browser/frame_host/render_widget_host_view_child_frame.cc
@@ -199,7 +199,12 @@ gfx::Vector2dF RenderWidgetHostViewChildFrame::GetLastScrollOffset() const {
 }
 
 gfx::NativeView RenderWidgetHostViewChildFrame::GetNativeView() const {
-  NOTREACHED();
+  // TODO(ekaramad): To accomodate MimeHandlerViewGuest while embedded inside

[Charlie Reis, 2016/09/07 00:22:29]

I don't understand-- can you elaborate why this case needs this change?

I'm concerned that this will conflict with wjmaclean's planned fix for
https://crbug.com/644294.  Can you coordinate with him?

[EhsanK, 2016/09/08 18:14:57]

The issue leading to this change is loading a pdf inside a <webview> with
--use-cross-process-frames-for-guests. The PDF is a BrowserPlugin and RWHVGuest
needs native view for size update. That will crash if RWHVCF returns null. Here
RWHVCF is the parent RWHV for the guest. This is one example of nested guests. 

+  // OOPIF-webview, we need to return the native view to be used by
+  // RenderWidgetHostViewGuest. Remove this once https://crbug.com/563285 is

[Charlie Reis, 2016/09/07 00:22:29]

I thought this CL was going to fix https://crbug.com/563285.  Did you mean to
say https://crbug.com/642826?

[wjmaclean, 2016/09/07 13:32:33]

Do we really want to remove this afterwards? It seems quite reasonable to me
that a RWHVCF should provide a NativeView* when asked (often this is just done
to query window settings, though in the case where it's done to change settings
we should be careful to ensure there are no conflicts).

[EhsanK, 2016/09/08 18:14:58]

Yes. Initially I did not have a tracking bug for PDF. The bug 536285 is about
PDF crash in the presence of oopif flag. This CL technically fixes that. But for
tracking the actual MimeHandlerView based on OOPIF issue I filed the new bug but
failed to update all comments accordingly.

+  // fixed.
+  if (frame_connector_)
+    return frame_connector_->GetParentRenderWidgetHostView()->GetNativeView();

[wjmaclean, 2016/09/07 13:32:33]

GetRootRenderWidgetHostView() instead of GetParentRenderWidgetHostView()?

[lfg, 2016/09/07 14:55:18]

I think parent is better than root in this case. It allows any frame in the tree
to view, intercept and modify the request if needed.

For example, RenderWidgetHostViewGuest has its own NativeView. In that case,
(hypothetically, since currently there's no OOPIFs inside guests), we would
return the wrong NativeView by bypassing all the frames in the tree.

When I added GetRootRenderWidgetHostView(), the intention was to solve a
specific problem: GetBoundsInRootWindow(), which can't be done otherwise; but
other than that, I think it should be used with care.

[EhsanK, 2016/09/08 18:14:57]

Also, but returning the parent, we always end up with the root anyway, won't we?

   return nullptr;

[wjmaclean, 2016/09/07 13:32:33]

At some point it would be nice to always return a non-null value (does a RWHVCF
ever *not* have a 'parent'), but for now we'll still need to make sure that
consumers check the return value.

[lfg, 2016/09/07 14:55:18]

That will happen during construction/destruction, where the frame_connector_ is
null. The only way to guarantee that this is non-null is by guaranteeing that
the callers never call this when the frame is being initialized/destroyed.

 }