Index: content/renderer/render_view_impl.cc |
diff --git a/content/renderer/render_view_impl.cc b/content/renderer/render_view_impl.cc |
index c9cbd6689944fbccc878e9e79f505e7f256630e5..47783669bf4f96b44c56ed0ac1658e1061f27572 100644 |
--- a/content/renderer/render_view_impl.cc |
+++ b/content/renderer/render_view_impl.cc |
@@ -729,6 +729,15 @@ void RenderViewImpl::Initialize(const ViewMsg_New_Params& params, |
main_render_frame_->set_render_frame_proxy(proxy); |
} |
+ // This breaks postMessage otherwise. |
+ // |
+ // The following assumption that we can use the WebRemoteFrame as the |
+ // main frame doesn't hold for <webview>, because our top level frame |
+ // is the guest's main frame. The proxy that created this WebRemoteFrame |
+ // is merely a proxy to the guest and is not part of the frame tree. |
+ // TODO(lazyboy): Find a solution here since this breaks regular OOPIF. |
+ webview()->setMainFrame(main_render_frame_->GetWebFrame()); |
+ /* |
// In --site-per-process, just use the WebRemoteFrame as the main frame. |
if (command_line.HasSwitch(switches::kSitePerProcess) && proxy) { |
webview()->setMainFrame(proxy->web_frame()); |
@@ -738,6 +747,7 @@ void RenderViewImpl::Initialize(const ViewMsg_New_Params& params, |
} else { |
webview()->setMainFrame(main_render_frame_->GetWebFrame()); |
} |
+ */ |
main_render_frame_->Initialize(); |
if (switches::IsTouchDragDropEnabled()) |