Closed Bug 927747 Opened 11 years ago Closed 9 years ago

MessagePort objects cannot be sent to the contentWindow of iframe[mozbrowser]

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 911972

People

(Reporter: sunhaitao, Assigned: sunhaitao)

Details

Attachments

(2 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20131016030202

Steps to reproduce:

0. Open |about:config|. Make sure that:
  * 'dom.messageChannel.enabled' is set to true
  * 'dom.mozBrowserFramesEnabled' is set to true
  * 'devtools.chrome.enabled' is set to true

1. Deploy the following code to "http://localhost:2063/index.htm"

  <!DOCTYPE html>
  <style>
  iframe[mozbrowser] {
    width: 100%;
  }
  </style>
  <iframe src="http://mozilla.org" mozbrowser=""></iframe>
  <script>
  var iframe = document.querySelector('iframe');
  iframe.onload = function() {
    var tc = new MessageChannel();
    var data = ['PORT_REQUIRED'];
    var ports = [tc.port2];
    try {
      iframe.contentWindow.postMessage(data, '*', ports);
    } catch (e) {
      data.ports = ports;
      iframe.contentWindow.postMessage(data, '*');
    }
  };
  </script>


2. Open a Scrachpad. Select "Envierment" to "Browser". Run the follwing code:

  Components.utils.import("resource://gre/modules/Services.jsm");
  function grantBrowserPermissionTo(targetUri) {
    Services.perms.add(Services.io.newURI(targetUri, null, null), 'browser', 1);
  }
  grantBrowserPermissionTo('http://localhost:2063/');

3. visit "http://localhost:2063/index.htm". Open the JavaScript console.



Actual results:

A DataCloneError will be found.



Expected results:

No Errors should be thrown.
Attached patch A hackish patch (obsolete) — Splinter Review
I've managed to make out a working patch, but I'm not sure whether the solution used is general and elegant enough.
Assignee: nobody → sunhaitao
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?
Flags: needinfo?
Unfortunately your patch is not good enough. iframe mozbrowser can run in a separated process.
This issue is similar to MessagePorts in workers where we have threads instead processes.
(In reply to Andrea Marchesini (:baku) from comment #2)
> Unfortunately your patch is not good enough. iframe mozbrowser can run in a
> separated process.
> This issue is similar to MessagePorts in workers where we have threads
> instead processes.

I used to think so too. But my recent test suggests that this solution WORKS on Gonk. Maybe the situation is simpler than we thought.
Attached file A Pilot App for B2G
The pilot app I used. It displays 'It works!' in a red border box when everything works.
Attachment #824522 - Flags: feedback?(amarchesini)
have you tested it on a real device? or on a b2g desktop multi process build?
Can then use the port and receive/send messages through it?
Tested on the B2G emulator for ARM. Both the port and the ports sent via it seem to be working fine.

I'm suspecting that this is because the 'remote' attribute doesn't actually affected in my pilot app. It only asked for 'browser' permission. Although it still works after adding a request to the 'embed-apps' permission.
Attached patch Bug927747.patch (obsolete) — Splinter Review
I Rebased the patch of Comment 1 on mozilla-central and added a mochitest into this patch. 

The patch didn't pass and I got the following error:
  TypeError: invalid transferable array for structured clone

@SUN Haitao, I don't get the expected result from the rebased patch. Could you help to check if this patch is correct.
Comment on attachment 826610 [details] [diff] [review]
Bug927747.patch

Review of attachment 826610 [details] [diff] [review]:
-----------------------------------------------------------------

You need a workaround in the mochitest.

::: dom/base/test/test_bug927747.html
@@ +41,5 @@
> +
> +    function iframeLoaded() {
> +      var error = null;
> +      try {
> +      ifr.contentWindow.postMessage(['PORT_REQUIRED'], '*', [ a.port2] );

Due to Bug 912456, this call won't success. Although it should be.

Currently you have to do like this:
  var data = ['PORT_REQUIRED'];
  data.ports = [ a.port2];
  ifr.contentWindow.postMessage(data, '*');
Attachment #826610 - Flags: review-
(In reply to SUN Haitao from comment #8)
> Comment on attachment 826610 [details] [diff] [review]
> Bug927747.patch
> 
> Review of attachment 826610 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> You need a workaround in the mochitest.
> 
> ::: dom/base/test/test_bug927747.html
> @@ +41,5 @@
> > +
> > +    function iframeLoaded() {
> > +      var error = null;
> > +      try {
> > +      ifr.contentWindow.postMessage(['PORT_REQUIRED'], '*', [ a.port2] );
> 
> Due to Bug 912456, this call won't success. Although it should be.
> 
> Currently you have to do like this:
>   var data = ['PORT_REQUIRED'];
>   data.ports = [ a.port2];
>   ifr.contentWindow.postMessage(data, '*');

Applied the above changes, I stll got different error message:
  [Exception... "The object could not be cloned." code: "25" nsresult: "0x80530019 (DataCloneError)"
(In reply to Yuan Xulei [:yxl] from comment #9)
> Applied the above changes, I stll got different error message:
>   [Exception... "The object could not be cloned." code: "25" nsresult:
> "0x80530019 (DataCloneError)"

Oh, you also need set "dom.mozBrowserFramesEnabled" to true.
Attachment #818860 - Attachment is obsolete: true
Attachment #826610 - Attachment is obsolete: true
OS: Windows 7 → All
Hardware: x86 → All
Version: 27 Branch → Trunk
Comment on attachment 826702 [details] [diff] [review]
Rebased, with more complete test.

Review of attachment 826702 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the mochitest. The issue is that with your test the iframe runs on the same process of the window.
And yes, this works. But on b2g many mozbrowser iframes run on separated process. You can try this adding: dom.ipc.browser_frames.oop_by_default in the pushPrefEnv and see if a new process is spawn.

::: dom/base/test/test_bug927747.html
@@ +65,5 @@
> +  SimpleTest.waitForExplicitFinish();
> +  SpecialPowers.pushPrefEnv({
> +      "set": [
> +        ["dom.messageChannel.enabled", true],
> +        ["dom.mozBrowserFramesEnabled", true]

add: "dom.ipc.browser_frames.oop_by_default" for a OOP mozbrowser iframe.
I discussed this with Xulei in Mozilla Space Beijing yesterday. We confirmed that:

* The 'remote' attribute in my tests never actually worked. It needs to be set to 'true' to affect.
* Due to bug 761935/879475, currently all mozbrowser iframes created by B2G apps (except the 'root' one) are in-process.
* An OOP mozbrowser iframe always has a null 'contentWindow' property. So actually, there's no way to post message to its content.

Basing on those facts, I suggest the following plan:

0. Refocus this bug on in-process situation only. Clean up the current patch and make it land.
1. Create a feature request on a mechanism to message content windows of OOP mozbrowser iframes. This step will depend on bug 914974.

Is this plan OK?
> Is this plan OK?

I uploaded a patch (WIP) for bug 911972 that implements MessagePort/MessageChannel using PBackground. This is the first step for having MessagePort in oop mozbrowser iframe and workers.
(In reply to Andrea Marchesini (:baku) from comment #14)
> I uploaded a patch (WIP) for bug 911972 that implements
> MessagePort/MessageChannel using PBackground. This is the first step for
> having MessagePort in oop mozbrowser iframe and workers.

I saw it yesterday. I'm trying understanding it now. I just can't wait to see the part to handle transferables (especially MessagePort objects).
Comment on attachment 824522 [details]
A Pilot App for B2G

I remove the feedback request. If you want we can continue the discussion about MessageChannel/MessagePort on bug 911972
Attachment #824522 - Flags: feedback?(amarchesini)
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: