[webkit-dev] Fwd: [whatwg] postMessage support now in Firefox trunk, implementation issues, feedback, tests

Wed Jan 30 00:27:54 PST 2008

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 <jwalden+whatwg at MIT.EDU>
> Date: January 29, 2008 10:36:51 PM PST
> To: whatwg at whatwg.org
> Subject: [whatwg] postMessage support now in Firefox trunk,  
> implementation issues, feedback, tests
> Reply-To: jwalden+whatwg at MIT.EDU
>
> 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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080130/8e988023/attachment-0001.html