summaryrefslogtreecommitdiffstats
path: root/content/browser/message_port_provider.cc
Commit message (Collapse)AuthorAgeFilesLines
* Switch to standard integer types in content/browser/.avi2015-12-251-1/+0
| | | | | | | | | BUG=138542 TBR=jam@chromium.org Review URL: https://codereview.chromium.org/1549113002 Cr-Commit-Position: refs/heads/master@{#366868}
* Cleanup the remaining references to source_view_idsgurun2015-08-191-7/+0
| | | | | | | | | | | | | BUG=473258 When Android webview implemented message ports, it set the source frame to target frame simply to be able transfer message ports, as blink required a valid source frame. Now the requirement is gone, cleanup the logic. Review URL: https://codereview.chromium.org/1297993005 Cr-Commit-Position: refs/heads/master@{#344302}
* Refactor postMessage for out-of-process iframes.alexmos2015-04-091-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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}
* This CL addresses a long standing TODO to implement transferring ports from ↵sgurun2015-03-121-0/+9
| | | | | | | | | | | | | | JS to Java. Note that this is the last piece of MessageChannel puzzle. With this, we can consider basic implementation done. There is a missing feature to implement posting messages to frames given with their names, but this has other dependency. We can now start further testing, optimization and refactorings. BUG=393291 Review URL: https://codereview.chromium.org/995663002 Cr-Commit-Position: refs/heads/master@{#320198}
* Hold messages in message port service when a message port issgurun2015-03-101-0/+14
| | | | | | | | | | | | | | | | | | | | | | being transferred. This CL addresses a long standing TODO for addressing message queuing. When Message ports are in flight, race conditions that lead to dropped messages, or ghost messages (messages arriving for already transferred ports can occur). To prevent this, messages are queued at the message port service during transfer. Note that this CL also restricts transferring message ports from Java to JS under certain circumstances. Basically, message ports that are already used for communication from Java to JS are not allowed to be transferred at the time. This restriction can be relaxed later. BUG=463269 Review URL: https://codereview.chromium.org/986553004 Cr-Commit-Position: refs/heads/master@{#319943}
* Step two of optionally sending messages to/from message ports as base::Value.mek2015-02-281-30/+13
| | | | | | | | | | | | | | | | | | | | This CL changes every place a MessagePort is transferred between process to properly propagate the send_messages_as_values flag, as well as makes it possible for NavigatorConnectContext to set this flag when setting up a new connection. This is part of a series of changes: [1/5] Blink side changes in https://codereview.chromium.org/924983002/ that expose a needed v8 context [2/5] https://codereview.chromium.org/921013002/ allow MessagePort to send messages as values [3/5] This CL [4/5] https://codereview.chromium.org/938403005/ which uses this for navigator.connect services and adds infrastructure for layout tests [5/5] https://codereview.chromium.org/940423004/ adds layout tests to blink to test these new features BUG=426458 Review URL: https://codereview.chromium.org/944443003 Cr-Commit-Position: refs/heads/master@{#318578}
* Optionally have MessagePort pass data as base::Value, part 1.mek2015-02-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Various efforts (android webview, navigator.connect) are experimenting with using MessagePort as a way to communicate with native code. This is a start at refactoring MessagePort code to make this possible. This CL changes the IPCs for MessagePort messages to pass the data as a MessagePortMessage struct, adding support to the renderer side MessagePort code to support both base::Value and blink::WebSerializedScriptValue messages. Additionally a (currently unset) flag is added that determines how MessagePort sends messages back to the browser process. This is part of a series of changes: [1/5] Blink side changes in https://codereview.chromium.org/924983002/ that expose a needed v8 context [2/5] This CL [3/5] https://codereview.chromium.org/944443003/ which causes the send_messages_as_values flag to be propagated [4/5] https://codereview.chromium.org/938403005/ which uses this for navigator.connect services and adds infrastructure for layout tests [5/5] https://codereview.chromium.org/940423004/ adds layout tests to blink to test these new features BUG=426458 Review URL: https://codereview.chromium.org/921013002 Cr-Commit-Position: refs/heads/master@{#318492}
* Implement the close() API for Message portssgurun2015-02-261-0/+7
| | | | | | | | | | | | | | | The close API has to consider these cases: 1. A message port can be in a pending state 2. A message could be queued in renderer waiting for conversion Therefore close() immediately closes the port, but it does not cleanup the resources until all the messages are transferred. BUG=393291 Review URL: https://codereview.chromium.org/956763002 Cr-Commit-Position: refs/heads/master@{#318271}
* Post a message from Java to JS using message channels.sgurun2015-01-291-0/+10
| | | | | | | | BUG=393291 Review URL: https://codereview.chromium.org/869133005 Cr-Commit-Position: refs/heads/master@{#313817}
* Enable posting a message from JS to Android webview.sgurun2015-01-231-31/+49
| | | | | | | | | | For future CL: queueing messages, sending messages from Java to JS through message channel, transferring ports in message channels, closing channels. BUG=393291 Review URL: https://codereview.chromium.org/831523004 Cr-Commit-Position: refs/heads/master@{#312922}
* Verify that Message Channel Message Ports can be transferred correctlysgurun2014-12-021-0/+2
| | | | | | | | | | | | | BUG=393291 Write a test to make sure Message Channel MesssagePorts can be transferred correctly from Webview to JS by testing communication between a Worker and the main frame. Also fix a bug discovered by this test. Review URL: https://codereview.chromium.org/766623002 Cr-Commit-Position: refs/heads/master@{#306449}
* Add a content API to create a message channel.sgurun2014-11-191-0/+68
BUG=393291 Add a content API to create a message channel. Android Webview will use this channel for communicating to JS. Also move postmessage related logic to its own class from webcontents. Review URL: https://codereview.chromium.org/387113003 Cr-Commit-Position: refs/heads/master@{#304873}