17099 2008-01-30 12:00:59 -0800 Add Mozilla tests for postMessage, fix bugs they reveal 2010-01-03 10:34:37 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC OS X 10.5 RESOLVED WONTFIX http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-May/014665.html InRadar P2 Normal --- 1 abarth webkit-unassigned annevk ap collinj jwalden+bwo sam sylvain.pasche webkit oldest_to_newest 68828 0 abarth 2008-01-30 12:00:59 -0800 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. 69006 1 webkit 2008-01-31 22:27:28 -0800 This test http://virtuelvis.com/download/2005/12/crossdocument/sender.html also doesn't work. 69008 2 sam 2008-01-31 22:47:25 -0800 (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. 69025 3 jwalden+bwo 2008-02-01 01:31:19 -0800 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. 69338 4 annevk 2008-02-04 04:57:45 -0800 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. :-) 74176 5 mrowe 2008-03-17 15:21:40 -0700 <rdar://problem/5803701> 80028 6 jwalden+bwo 2008-05-09 15:58:13 -0700 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. 80030 7 jwalden+bwo 2008-05-09 16:02:04 -0700 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) 80035 8 jwalden+bwo 2008-05-09 16:06:16 -0700 (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! :-) ) 80047 9 collinj 2008-05-09 18:52:42 -0700 (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) 80049 10 jwalden+bwo 2008-05-09 19:42:43 -0700 (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. 80159 11 21077 abarth 2008-05-12 00:32:12 -0700 Created attachment 21077 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. 176429 12 sam 2010-01-03 10:34:37 -0800 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. 21077 2008-05-12 00:32:12 -0700 2008-05-12 00:32:12 -0700 Use lexical scope lexical-post-message.patch text/plain 574 abarth SW5kZXg6IFdlYkNvcmUvYmluZGluZ3MvanMvSlNET01XaW5kb3dDdXN0b20uY3BwCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0KLS0tIFdlYkNvcmUvYmluZGluZ3MvanMvSlNET01XaW5kb3dDdXN0b20uY3BwCShyZXZpc2lv biAzMzAzOCkKKysrIFdlYkNvcmUvYmluZGluZ3MvanMvSlNET01XaW5kb3dDdXN0b20uY3BwCSh3 b3JraW5nIGNvcHkpCkBAIC0yMDQsNyArMjA0LDcgQEAgSlNWYWx1ZSogSlNET01XaW5kb3c6OnBv c3RNZXNzYWdlKEV4ZWNTdAogewogICAgIERPTVdpbmRvdyogd2luZG93ID0gaW1wbCgpOwogCi0g ICAgRE9NV2luZG93KiBzb3VyY2UgPSBhc0pTRE9NV2luZG93KGV4ZWMtPmR5bmFtaWNHbG9iYWxP YmplY3QoKSktPmltcGwoKTsKKyAgICBET01XaW5kb3cqIHNvdXJjZSA9IGFzSlNET01XaW5kb3co ZXhlYy0+bGV4aWNhbEdsb2JhbE9iamVjdCgpKS0+aW1wbCgpOwogICAgIFN0cmluZyBtZXNzYWdl ID0gYXJnc1swXS0+dG9TdHJpbmcoZXhlYyk7CiAKICAgICBpZiAoZXhlYy0+aGFkRXhjZXB0aW9u KCkpCg==