Maciej, I filed this as <http://bugs.webkit.org/show_bug.cgi?id=17099>. I should be able to take a look at this over the next week. Let me know if you'd like me to give this higher priority.
Adam On Jan 30, 2008 12:27 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > > Jeff Walden mentioned on IRC that some of the tests mentioned below fail in > WebKit TOT and seem to show cross-domain postMessage not working (I suspect > it's failing security checks for some unrelated reason). Can someone > (ideally someone who understands postMessage) please try these? I'm afraid > the steps are a little complicated. > > I'm also curious if the PAC file approach would be a viable way to do > cross-domain security testing more generally (it is able to test different > subdomains and ports unlike our current approach). > > Begin forwarded message: > > From: Jeff Walden <[EMAIL PROTECTED]> > Date: January 29, 2008 10:36:51 PM PST > To: [EMAIL PROTECTED] > Subject: [whatwg] postMessage support now in Firefox trunk, implementation > issues, feedback, tests > Reply-To: [EMAIL PROTECTED] > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=postMessage > > I just landed HTML5 postMessage support in Firefox, so it should be in > Firefox 3! Thanks to WebKit people for pushing on this, because I didn't > think this had a chance of making 3, to be utterly honest, having tried once > before several months ago. To be honest, I'm still in a state of shock this > got taken. :-) > > > First: > > I strongly encourage all implementers of postMessage to compare how they do > against the set of tests (for both postMessage and MessageEvent > functionality) that I wrote during implementation of postMessage. I made > special efforts not to do any Mozilla-specific testing without a user-agent > guard, and I don't believe there are any unguarded Mozilla-specific tests > any more -- and to an extent nothing not specified by HTML5 or otherwise > commonly implemented, more or less. There's significant bustage against the > tests in the user agents I tested even on basic functionality, to the extent > that the API's not usable for what it was intended due to incorrect errors > being thrown on access and such. (I've guarded against these problems in > the tests with try/catches and "sentinel" timeout checks when there's no > other way to communicate a failure). The tests are available here: > > http://web.mit.edu/jwalden/www/whatwg/postMessage.zip > > To run the tests, extract them somewhere on your hard drive and start an > HTTP server on port 8888 serving the postMessage/ folder as its root folder. > Make sure that your server will serve .xhtml files with the XHTML MIME-type > -- a couple tests use it because I was too lazy to use external files for > scripts and wanted to include special characters literally (or wanted to > test specific Unicode-related handling). Next, set up proxy autoconfig in > your UA to point to <http://localhost:8888/proxy.js>. Now navigate to: > > http://localhost:8888/tests/dom/tests/mochitest/whatwg/ > > From there click the "Run tests" link to see how you do. For individual > test results, see the individual test links. Be very careful when you run > these -- the uri-checking hard-codes URIs instead of using something like > location.href in the interest of robustness against colluding failures, so > running with, say, a stray hash or question mark at the end of a page URL > will usually cause that test to fail. > > I spent a lot of time on these tests, and I'm not aware of any bugs in them, > but I'd very much appreciate people reading through them, running them, and > checking for any errors I might have made, say, in not marking a test as > Moz-specific or such (subject to the points noted below). > > > Second: > > The spec's incomplete or vague on a few points right now. The points I know > where I forged new ground or think clarifications/explicit notes may be in > order are: > > * event.domain/uri values in a rewritten about:blank document > The spec seems to somewhat indicate that we should be using about:blank and > "" as uri/domain right now, but that's fairly useless in terms of allowing > postMessage in dynamically-created pages. This probably wants to change to > reflect the document's origin/principal, and assuming things go the way most > browsers have implemented it, this means those values are the same as for > the opener of about:blank. This is tested in > test_postMessage_special.xhtml. Note that there are two different tests of > this behavior which change the document in slightly different ways, and > Mozilla expects them to have the same results right now. > > * event.domain/uri values in data: URLs > Mozilla currently gives data: URLs the principal of the opener/parent, so we > use that URI for computing uri/domain of messages from data: URLs. The two > tests for this are UA-guarded for now as behaviors differ across browsers on > this, but in the long run everyone should come to an agreement on this. > > * event.domain with non-standard ports > We have it so domain doesn't include the port number, ever. The spec says > this, but it's not absolutely explicit. > > * event.domain/uri values for IDN URLs > We use the Unicode-ized values of these, not the Punycode versions. > (Actually, that's a lie -- what we use depends on whether the relevant TLD > is whitelisted for non-punycode display or not, which is clearly the wrong > behavior; at the moment I doubt this will be fixed for Firefox 3, sadly.) I > think this is what authors would most likely expect, if not now then when > IDN is truly widespread (when we'd be stuck with punycode if we were to > choose it now), but the spec doesn't say anything about IDN yet. > > * event.domain/uri when calling through another same-origin page > Page A and B are same-origin; A calls a method in B, which calls > postMessage. The dispatched event has uri/domain of B, not of A. The > spec's reasonably clear on this, but best to note it explicitly here. > > * event.domain for non-hierarchical URLs > I don't test this because I'm aware of no common protocol that would be > cross-browser, but .domain would be the empty string, not null, in this > case. If we ever changed the behavior of data: URLs, I suspect we'd hit the > logic to return an empty string. > > * event.domain when document.domain has been changed > The value of event.domain is the original domain for the page, not the value > to which document.domain may have been set. > > * handling a postMessage-dispatched MessageEvent by throwing > Any exceptions thrown by exception handlers when postMessage is called on a > window are ignored; they are not propagated up to an exception handlers. In > particular, this happens regardless of the origin of the window whose script > threw an exception, even if it is identical to that of the window that > called postMessage. It doesn't seem like a good design to me to have to > check for a pending exception and only allow it if the target had the same > origin; best to avoid the problem entirely and just unconditionally prevent > any exceptions from propagating rather than introduce the possibility of > error in determining when an exception may be safely propagated. (Also > consider that if you were to propagate in the cross-origin case you'd have > to make sure the thrower hadn't set any properties on the exception, or at > least that said properties would not be accessible to the postMessage > caller.) > > > (One last note that's relevant yet not relevant: if you're wondering what > Mozilla does for "chrome" content that runs with elevated privileges, we > forcibly make the source of the dispatched events null. In this way chrome > can postMessage chrome or content, but no method is provided for response or > even for referring to the sender. To respond, the target window must be > able to get a reference to the sending window some other way.) > > > > That covers everything I ran into while implementing this; comments, > suggestions for other tests, complaints about test bugs, suggestions for > error message clarifications, yadda yadda are all greatly appreciated! > > Jeff Walden > > P.S. -- Mailman, you suck for not using using the various vendor-specific > and standard forms of pre-wrap on the ASCII emails you display, and I refuse > to acquiesce to your demands for line breaks in what I type. > > > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo/webkit-dev > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
