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 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:/proxy.js. Now navigate to:
http://localhost:/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,
