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

[Adam Barth]

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 <mjs at apple.com> 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 <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.
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>