Allow MimeHandlerViewGuest be embedded inside OOPIFs

content/public/browser/browser_plugin_guest_delegate.h

Index: content/public/browser/browser_plugin_guest_delegate.h
diff --git a/content/public/browser/browser_plugin_guest_delegate.h b/content/public/browser/browser_plugin_guest_delegate.h
index d689b944d456033842a014c5d120e4ef7d522072..39b045b14c56baea9255517225823a0ac7cdfc90 100644
--- a/content/public/browser/browser_plugin_guest_delegate.h
+++ b/content/public/browser/browser_plugin_guest_delegate.h
@@ -93,6 +93,15 @@ class CONTENT_EXPORT BrowserPluginGuestDelegate {
   // a BrowserPlugin even when we are using cross process frames for guests. It
   // should be removed after resolving https://crbug.com/642826).
   virtual bool CanUseCrossProcessFrames();
+
+  // Returns the RenderFrameHost corresponding to the RenderFrame embedding the
+  // BrowserPlugin. This is the main frame for the owner of the guests, unless
+  // the guest is embedded inside a cross origin frame.

[Charlie Reis, 2016/11/15 23:45:33]

Sorry, I don't think this API makes sense.  The first sentence is incorrect if
the BrowserPlugin is inside a same-origin iframe rather than the main frame.

It may happen to work out because the current callers only care about
widget-level concepts (RWHV, process, SiteInstance), but it will break any
future code that assumes it returns the actual embedding frame.

Would returning the owner RenderWidgetHost or RenderWidgetHostView work instead?
 Maybe with a separate GetOwnerSiteInstance since RenderWidgetHost doesn't know
its SiteInstance?

[EhsanK, 2016/11/16 21:27:31]

Yes you are right. I was too focused on the OOPIF case when adding this comment.
Agreed. Basically, the whole guest->embedder communication is through the
RenderWidgetHost.
Done.

+  virtual RenderFrameHost* GetOwnerFrame();
+
+  // Returns true if the corresponding guest is allowed to be embedded inside an
+  // <iframe> which is cross process.
+  virtual bool CanBeEmbeddedInsideCrossProcessFrames();
 };
 
 }  // namespace content