[whatwg] More on postMessage

[Jeff Walden]

In my previous email regarding HTML5's postMessage (section 6.4, cross-domain communication), I suggested changing the API to |yourWindow.postMessage(message, otherWindow)|.  I have a few more questions/suggestions after playing around with an implementation of this in Mozilla (bug postMessage for anyone who cares); I somewhat hope to get this in 1.9.


First, I think placing |otherWindow| as the first argument and |message| as the second is more aesthetically pleasing than the other way around, tweaking the suggestion I made last time.  I don't have a strong reason for this beyond its being analogous to the traditional security model in the literature (which seems good enough to me in the absence of strong reasons going the other way):

  yourWindow  .  postMessage ( otherWindow , message ) ;
     actor   does    verb    to   object


Second, in the interests of explicitness, we should be clear about the exact values of event.domain and event.uri.  Two concerns: how does setting document.domain interact with the computed value for event.domain, and what are the contents of event.domain in the presence of default and non-default ports?  I think the answers to these two concerns must be as follows.  Setting document.domain must have no effect on the value of event.domain, in the interests of web hosts who host content on subdomains of their main domain, e.g. myhomepage.webhost.com and webhost.com (else it would allow spoofing in pages which listened for cross-domain messages but didn't check the uri).  The contents of event.domain must include the port number iff it is not the default port number for the protocol (80 for http, 443 for https) and must omit it otherwise.


Third, with the modified API, the following is possible:

  // kidFrame is same-origin wrt window
  window.frames.kidFrame.postMessage(otherWindow, message);

With the current design, this would basically allow a window to send an event which looks as though it has been created by another (same-origin, or joined-principals via document.domain) window, with a different event.uri.  Since the two windows are same-session this probably isn't a real concern, but I think it's worth mentioning that the change makes it possible to send a message from a window different from the one currently executing the script.


Fourth, and probably most importantly, is the event dispatched by postMessage dispatched synchronously (event fired and processed before postMessage returns) or asynchronously?  I interpret the current wording to mean synchronously, in accordance with the DOM 3 Events section on reentrance, but I'd like to be clear that's the intended interpretation.


Jeff