Enabling Mashups in Internet Explorer 8 with Cross Document Messaging


Hello, I’m Sunava Dutta and I’m the Program Manager focused on improving our AJAX scenarios in IE8. In this short post I’ll introduce you to a feature we’re implementing in the browser that enables safer mashups. The Same Origin Policy (SOP) requires that browsers prevent script from accessing the contents of another domain to prevent cross site script attacks. Web sites today, like Facebook and Live among others, allow users to drag and drop third party ‘gadgets’ or applications to their page. As the BBC News reports, there are many challenges to doing so safely. These components are usually embedded third party scripts. Unfortunately these third party scripts run with the same privileges as the parent page and can potentially access personal data, cookies and other credentials. Attempts are currently underway to secure such script based applications. Other forms of embedding applications exist such as inserting the gadget in an IFrame, however while these are more secure they can’t communicate with the page and aren’t as useful.

In order to allow rich mashup scenarios where components can exchange information and permissions with the parent page, the IE team and other members of the HTML 5.0 Working Group are developing a cross document messaging feature. Communication using strings is enabled by a postMessage method. Hosting pages or gadgets are advised to check the origin domain of the content before inserting it in its DOM. For more details, please refer to our MSDN Dev Center Article on cross document messaging.

Sunava Dutta
Program Manager

Edit: added “more” to last sentence in first paragraph

Comments (23)

  1. Jeff Walden says:

    Note that the interface implemented by the current IE8 beta lags the HTML5 specification by several revisions in backwards-incompatible ways, so if you’re going to experiment with this, be aware that what you’re doing will break in a future revision of IE8.

    To save a little effort, the changes are as follows:

    – domain/uri properties are replaced with a single "origin" property, basically everything before the start of the path in a URI (excluding the username/password part) — so http://example.com, http://example.org:8080, etc.

    – window.postMessage requires two arguments, the first being the message, the second being the expected origin of the target window, in the same format as above; if the target window’s location doesn’t match this argument, nothing happens

    – window.postMessage dispatches events asynchronously, so after you dispatch you have to return from your event handler to allow the postMessage event to be dispatched

    – the target of the event is the window on which you called postMessage, not the document within it

    The Mozilla Developer Center also has good documentation of postMessage which may be useful:

    http://developer.mozilla.org/en/docs/DOM:window.postMessage

    I think that covers all the relevant bases, but of course, refer to the  spec for exact details (URI in previous comment).

  2. Jeff Walden says:

    By the way, commenting on this post consistently failed in Firefox 2 — probably want to investigate that and figure out what’s wrong.

  3. Jim says:

    There’s a good article on this here:

    http://virtuelvis.com/archives/2005/12/cross-document-messaging

    You can try it out in Opera, which already supports this feature.

  4. Jeff Walden says:

    Be careful with the Opera link, too — it describes an even *earlier* version of the method that puts the method on document.  I think their latest betas moved to window, but they haven’t made the uri/domain to origin change or most of the changes I mentioned in my first comment, either.  As I understand it, only Firefox 3 RC1 and recent WebKit nightlies are fully up-to-spec on this.  It’ll be awesome once everyone’s up to spec so we can really start playing with this stuff.

  5. Jeff Walden says:

    Hm, now commenting from Firefox 2 is succeeding.  I have no idea what’s going on here.

  6. Awesome Bar says:

    The text selection options in the IE8 location bar are much better than any previous version of IE however the location bar falls massively short of the utter brilliance of the Firefox 3 location bar.

    http://www.dria.org/wordpress/archives/2008/04/17/628/

    Awesome Bar indeed!  I certainly hope that the IE team manages to pull off something good with IE8 and that the location bar is actually far from code-complete.

  7. Rob says:

    "Note that the interface implemented by the current IE8 beta lags the HTML5 specification by several revisions…"

    Every blog post and article should include that statement about IE and any current or edge technology.

  8. untitled.bmp says:

    untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  untitled.bmp  

    sorted that crap coding problem yet in IE8?

  9. untitled.bmp says:

    untitled.bmp  

    sort it out!

  10. AH says:

    Just hoping for a fully-styleable HR element in IE8

    as well as the optional lightweight Document object (as FF, Opera, Safari all have)

  11. AH says:

    Oh, and I’m glad to hear you’re finally working with WHATWG on HTML5, if I read this correctly 🙂

  12. billybob says:

    I see it is the same Microsoft here… WHY does your version of a standard function always have to be slightly different to the actual spec?

    For a start, your function declaration is different to the one in the spec and makes the second parameter optional.  Your documentation does not specify what happens if you do not specify the target origin.

    In addition you break a number of the 5 steps you MUST take.

    1.  According to the spec, not supplying targetOrigin should result in a SYNTAX_ERR exception being thrown but your version allows it to be null.

    2. Your documentation says "The postMessage method call does not return until the event listeners of the target document have finished executing." which is in direct contradiction with the spec which says it should return as soon as it has validated the targetOrigin.

    Please explain…

  13. Jeff Walden says:

    To be fair, the spec only recently changed to what it is now from what Microsoft had implemented, so it’s not entirely fair to complain that Microsoft implemented the spec incorrectly — they were correct as of a few weeks ago!  Very few changes can or should be made with that sort of immediate turnaround without degrading quality or corrupting the development process (and in any case, IE betas don’t happen nearly as often as nightlies from other browsers, so it still might have been awhile after the fix anyway).

    That said, I’m not sure why they posted this article so early knowing that their implementation was tracking an older version of the spec which is incompatible with the current version.  It seems like it would have been better for everyone if they’d updated to match the latest spec and only then made this post.

  14. Mitch 74 says:

    Let’s just hope that they will actually update the implementation – you just have to see how ‘fast’ updating the event object was to get anxious about this, too!

    A little history… IE 4 implemented the event object according to a W3C draft, in 1996 (or early 1997) if my memory serves me well. Following that, the W3C event object was made more flexible in order to cover the Netscape event model too – leading to the current W3C event model.

    Since then, some developers hoped for an update in IE 5 (1998), IE 5.5 (1999) or IE 6 (2001); not luck here. Again, in IE 7 (2006): no cigar. And it doesn’t seem to be intended for IE 8 either.

    Strangely, Opera (and Webkit/KHTML too) has been able to implement both models without too much trouble, as the W3C model is actually a superset of IE’s model: so, backward compatibility can be kept (methods have different names) and standards support improved (IE is the only current browser not supporting the W3C event model).

    All in all, in ten years the event object has progressed a whopping… er… Nothing. In IE.

    Let’s hope HTML5 mashups update will be infinitely faster…

  15. Geld Lenen says:

    Jim, thanks for that article, really informative. A good site also!

  16. Michael says:

    thanks for this article about "mashups" !

  17. IEBlog says:

    Yesterday at Tech Ed IT Pro 2008 in Orlando we announced some of the enhancements we’re making in Internet

  18. IEBlog says:

    Sunava Dutta here, a program manager focused on improving AJAX in the browser! Now that Internet Explorer

  19. С вами Сунава Дутта (Sunava Dutta), программный менеджер Internet Explorer. В мои обязанности входит

  20. IEBlog says:

    Today we’re excited to release the final build of Internet Explorer 8 in 25 languages. IE8 makes what

  21.     올랜도에서 개최된 Tech Ed IT Pro 2008 (영어) 에서 Internet Explorer 8 을 조직내에서 배포, 관리하기 위해, 몇가지 기능을