Bug 17099 – Add Mozilla tests for postMessage, fix bugs they reveal

• Component: Tools / Tests
• Status: RESOLVED WONTFIX

[Adam Barth]

Jeff Walden has posted the Mozilla regression tests for postMessage to the WHATWG mailing list:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-January/013795.html

He says that WebKit fails a number of these tests.  We should convert them to LayoutTests, add them to our test suite, and fix the bugs they reveal.

[Robert Blaut]

This test http://virtuelvis.com/download/2005/12/crossdocument/sender.html also doesn't work.

[Sam Weinig]

(In reply to comment #1)
> This test http://virtuelvis.com/download/2005/12/crossdocument/sender.html also
> doesn't work.

I believe this doesn't work because it is using the following
  var receiver = document.getElementsByTagName("iframe")[0].contentDocument;
  receiver.postMessage(val);

The issue is that it is using contentDocument instead of contentWindow.  postMessage is a function of the window, not the document.

[Jeff Walden (remove +bwo to email)]

Opera pioneered postMessage on document; HTML5 puts it on window.  Given that IE7 no longer allows cross-origin access to documents and Firefox 3 is following in its footsteps, and given that narrowing the cross-origin attack surface to just window is better security-wise, I don't think the location of postMessage will change, for what it's worth.

[Anne van Kesteren]

We have changed our (Opera) implementation though it might take some time (two weeks max I'm hoping) before it propagates to a public release. At that point hopefully we can do some joint testing together to ensure people can actually use this. :-)

[Mark Rowe (bdash)]

<rdar://problem/5803701>

[Jeff Walden (remove +bwo to email)]

Tests updated to latest spec, a second time since original posts.

Current failures I see, latest source:
- not throwing security exception accessing variable in other window (returning
  undefined, presumably); not inherently postMessage-related
- event.target is document (but target of dispatch is correctly window)
- some funkiness related to a closed-window test, not sure what's up with it
- you choke with a SYNTAX_ERR if targetOrigin is IDN
- you're using the value of document.domain for determining origin -- you
  should use the actual location
- data: URI origins not following HTML5 spec mean a test where a data: URI
  reaches into its parent ends up failing

The fifth is probably most important -- it's a spoofing concern for hosts which give out subdomains (although at least it isn't a two-way channel unless "*" is used with the response, rather only subdomain->other).  Fourth is next because it's not immediately obvious the failure would always be an exception thrown, and if it's a fail any way it'll be completely silent.  Second depends how smart code is at recognizing that, excepting listeners set across pages, .target === window -- I'd bet it'd be fairly rare.  The others are worth fixing but are either edge-case behavior or behavior that was one way but the spec now says do something else, so they're not super-duper important right now.

[Jeff Walden (remove +bwo to email)]

Oh, forgot:
- something appears to truncate origins at the first null character, so
  "http://lo\0k.com" appears to be interpreted as "http://lo" (at the least, it
  doesn't throw)

[Jeff Walden (remove +bwo to email)]

(In reply to comment #6)
> - you're using the value of document.domain for determining origin -- you
>   should use the actual location
> 
> The fifth is probably most important -- it's a spoofing concern for hosts
> which give out subdomains (although at least it isn't a two-way channel
> unless "*" is used with the response, rather only subdomain->other).

On second thought, I have no reason to believe it's not two-way; I don't think I tested that in the tests, and my reason for believing it was pure mental rationalization.

(Last time I bugspam in this bug today, I promise!  :-) )

[Collin Jackson]

(In reply to comment #6)
> - you're using the value of document.domain for determining origin -- you
>   should use the actual location

I was not able to reproduce this issue on the latest nightly. I typed this sequence of commands into the JavaScript console:

> document.domain = "webkit.org";
> addEventListener("message", function(e) { alert(e.origin); }, true);
> postMessage("hi", "*");

An alert pops up that says "https://bugs.webkit.org/" (not "https://webkit.org", which would be wrong)

[Jeff Walden (remove +bwo to email)]

(In reply to comment #9)
> I was not able to reproduce this issue on the latest nightly.

I think I was mistaken.  The first test that demonstrated this was succumbing to a previous error that snowballed and claimed to have received the wrong origin, but it was switching on a flawed .data property to determine it had received the wrong origin.  The second test is this one:

http://localhost:8888/tests/dom/tests/mochitest/whatwg/test_postMessage_onOther.html

The failure I get is:

not ok - unexpected origin got "http://example.com", expected "http://test1.example.com"

Either what's happening here is that document.domain is being used or (more likely given your example) the method used to determine the origin of the caller doesn't know that when A.bar() calls B.baz(), where baz was defined inside a script included by B's document, and B.baz() then calls postMessage, the origin to use is B's origin (more precisely, the origin of baz()) and not the origin of A (more precisely, A.bar()).  I think I recall seeing the latter at one other time when I was comparing tests against another implementation, so I'm betting the latter is the real problem.

[Adam Barth]

Created attachment 21077 [details]
Use lexical scope

This is because we're in the middle of switching from using the dynamic scope for authorization to using the lexical scope.  I've attached an (untested) patch that switches postMessage over to lexical scope.  I'm not sure if this is correct vis-a-vis WindowShell.  I don't understand that code yet.

[Sam Weinig]

I don't think there is anything to do with this bug anymore.  The tests noted in the mailing list will not pass in WebKit due to spec changes and WebKit updating to match.  If there is an updated suite, please re-open the bug.