diff options
| author | alexmos <alexmos@chromium.org> | 2015-04-08 19:22:16 -0700 |
|---|---|---|
| committer | Commit bot <commit-bot@chromium.org> | 2015-04-09 02:22:55 +0000 |
| commit | e7da5a1508504fded712749adc154a69424afa9e (patch) | |
| tree | 0833e47753f396c87f1b0c6d0167b4b1e5fdd930 /content/browser/message_port_provider.cc | |
| parent | dfa26626d7ffc17eba0942e60a1ce8818f8aaa42 (diff) | |
| download | chromium_src-e7da5a1508504fded712749adc154a69424afa9e.zip chromium_src-e7da5a1508504fded712749adc154a69424afa9e.tar.gz chromium_src-e7da5a1508504fded712749adc154a69424afa9e.tar.bz2 | |
Refactor postMessage for out-of-process iframes.
This CL moves cross-process postMessage plumbing from RenderView
to RenderFrame:
- The renderer-to-browser RouteMessageEvent message is now sent
through RenderFrameProxy rather than a swapped-out RenderView.
- The bulk of WebContentsImpl::RouteMessageEvent is moved into
RenderFrameProxyHost::RouteMessageEvent. Unfortunately, we still
need to call up to WebContents for dealing with <webview> and
on-demand creation of swapped-out RVs for the opener chain. This
will be cleaned up as part of https://crbug.com/225940.
- the browser-to-renderer PostMessageEvent message is now handled in
RenderFrameImpl::OnPostMessageEvent, instead of RenderViewImpl.
These changes make it possible to send messages between cross-process
subframes when in --site-per-process mode. This is exercised in a new
test, SitePerProcessBrowserTest.SubframePostMessage. More work will
be needed to support postMessages involving subframes in cross-process
openers (see https://crbug.com/225940 and https://crbug.com/423587).
With this change, the RFHM::SupportCrossProcessPostMessage test now
works in --site-per-process mode, so it is enabled on the Site
Isolation FYI bots.
BUG=389721
TBR=jam@chromium.org
Review URL: https://codereview.chromium.org/1046933005
Cr-Commit-Position: refs/heads/master@{#324341}
Diffstat (limited to 'content/browser/message_port_provider.cc')
| -rw-r--r-- | content/browser/message_port_provider.cc | 13 |
1 files changed, 9 insertions, 4 deletions
diff --git a/content/browser/message_port_provider.cc b/content/browser/message_port_provider.cc index eb932d9..ddd19ad 100644 --- a/content/browser/message_port_provider.cc +++ b/content/browser/message_port_provider.cc @@ -11,7 +11,7 @@ #include "content/browser/renderer_host/render_process_host_impl.h" #include "content/browser/renderer_host/render_view_host_impl.h" #include "content/browser/web_contents/web_contents_impl.h" -#include "content/common/view_messages.h" +#include "content/common/frame_messages.h" #include "content/public/browser/message_port_delegate.h" namespace content { @@ -25,12 +25,17 @@ void MessagePortProvider::PostMessageToFrame( const std::vector<TransferredMessagePort>& ports) { DCHECK_CURRENTLY_ON(BrowserThread::UI); - ViewMsg_PostMessage_Params params; + FrameMsg_PostMessage_Params params; params.is_data_raw_string = true; params.data = data; // Blink requires a source frame to transfer ports. This is why a // source routing id is set here. See WebDOMMessageEvent::initMessageEvent() - params.source_routing_id = web_contents->GetRoutingID(); + // TODO(alexmos, sgurun): Clean this up once crbug.com/473258 is fixed. + // Once message ports can work with a null source frame, + // source_view_routing_id can be removed, and this can just pass in + // MSG_ROUTING_NONE for the source frame. + params.source_view_routing_id = web_contents->GetRoutingID(); + params.source_routing_id = MSG_ROUTING_NONE; params.source_origin = source_origin; params.target_origin = target_origin; params.message_ports = ports; @@ -41,7 +46,7 @@ void MessagePortProvider::PostMessageToFrame( BrowserThread::IO, FROM_HERE, base::Bind(&MessagePortMessageFilter::RouteMessageEventWithMessagePorts, rph->message_port_message_filter(), - web_contents->GetRoutingID(), params)); + web_contents->GetMainFrame()->GetRoutingID(), params)); } // static |