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.
This test http://virtuelvis.com/download/2005/12/crossdocument/sender.html also doesn't work.
(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.
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.
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. :-)
<rdar://problem/5803701>
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.
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)
(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! :-) )
(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)
(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.
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.
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.