HTML5 Implementation Issues in IE8 (and later)

IE8 introduced support for some of the more stable features in the HTML5 spec. However, web developers have reported some problematic scenarios in IE8's support for these features, as described below.

1. postMessage only works for IFRAMES/FRAMES

The HTML5 postMessage function provides a great way for mutually distrusting documents (even cross-domain) to communicate securely and with high performance and reliability. Unfortunately, as reported on Connect, the HTML5 postMessage function does not work between tabs/windows in IE8. (This limitation is an artifact of the Loosely-Coupled IE feature, in which content in different tabs/windows may run in a different process.)

Attempting to send a message to a different window or tab results in an exception with the text "Error: No such interface supported." You can test for this problem at the following test page. Click the Create Popup button and then in the popup window, click the Call postMessage directly button to attempt to send a message to the subframe from the popup window. In IE8, this demo will fail and the script will display the exception.

The test page demonstrates one case where there is a workaround for this problem. If the popup window instead calls a script function in its window.opener page (click the Call opener's proxy function button), that script function can call postMessage to send a message to the child frame. Unfortunately, this workaround often isn't possible, because same-origin-policy dictates that the popup window and the window.opener page must be from the same origin in order to call each other's script functions.

Update: As of IE11, this issue has not yet been fixed. Bug Tracker

2. sessionStorage isn't properly shared between child frames

By design, the HTML5 sessionStorage feature is designed such that even tabs within the same browser session have independent sessionStorage objects.  If you change a sessionStorage attribute’s value in one tab, that change should not be reflected within another tab, even within the same browser session. 

However, sessionStorage is intended to be isolated per top-level-browsing-context, meaning that a page and any subframes on that page are intended to share sessionStorage values. IE8 does not reliably share sessionStorage objects between frames on a page.

A test page demonstrates this problem. Choosing a color from any of the three select controls on the page does the following:

• Sets a cookie named sessionColor containing the color name
• Sets a sessionStorage property named sessionColor to the color name
• Sets a localStorage property named sessionColor to the color name

A timer runs in each frame.  Every 500 milliseconds, the timer does the following:

• Changes the background color of the frame to the color specified in the cookie.
• Updates the display of the current localStorage.sessionColor value
• Updates the display of the current sessionStorage.sessionColor value
• Updates the Current time value

When interacting with the demo in IE8, you will likely notice that while the cookie/backcolor changes properly across the frames, often one or more of the sessionStorage values are not properly updated.

Unfortunately, there's no trivial workaround for this problem; a page can use the postMessage function to push state changes between frames, but this is somewhat more complex than simply querying the value of properties on the sessionStorage object.

Update: This issue appears to be resolved in IE11.

3. Changes to localStorage values are not reflected across active tabs/processes 

In contrast to sessionStorage, localStorage is meant to be shared across all browser instances, much like a persistent cookie. However, Internet Explorer's new session command does not properly interact with localStorage, so new browser sessions do not properly share localStorage information with other instances.

Using the same test page as in the previous example, change the localStorage session color to, say, blue. Then, use File > New Session to open a new browser session. Navigate that new window to the test page, and observe that while the background color of the page is properly reset (because session cookies are isolated by session) the localStorage value is improperly reset. You will notice that changing the localStorage values in the new session does not impact the local storage values of the prior session. Such isolation is not intended.

Update: As of IE11, this issue has not yet been fixed.

4. sessionStorage / localStorage are not isolated by scheme

In the current HTML5 working draft, Storage is defined to be isolated by origin; in IE, an origin consists of a scheme and fully-qualified hostname. In IE's implementation of Storage, only the fully-qualified hostname is evaluated. This means that HTTP pages can interact with the storage for HTTPS pages. You can see this by examining the sharing of the sessionStorage and localStorage values when navigating between the HTTPS Test Page and HTTP Test Page.  

Update: This issue was fixed as in IE9; pages in IE9+ Browser Mode will properly isolate storage by the protocol scheme. Compatibility View sites maintain the incorrect behavior.

A Caveat about InPrivate Browsing

Note that scenarios #2 and #3 intentionally have somewhat different isolation behaviors when browsing with an InPrivate Browsing session instance. InPrivate Browsing sessions are intentionally isolated, and cookies and storage values intentionally start blank and are intentionally cleared at the end of the browser session.

-Eric Lawrence

Appendix
Cross-browser remarks: Firefox 3.5.3 and Safari 4.0.2 had no problem with scenarios #2, #3. Opera 10 and Chrome 3.0.195.21 could not complete the test because they do not support the storage objects. When using the "Private Browsing" feature, Safari throws a "Quota exceeded" exception when trying to use the storage objects. None of these browsers had problems with scenario #1.

• Anonymous
  September 15, 2009
  Problem #1 is interesting.  It makes me wonder what sort of internal architecture could lead to that bug.

• Anonymous
  September 16, 2009
  @Adam: I assume that #1 is an artifact of the LCIE architecture(http://blogs.msdn.com/ie/archive/2008/03/11/ie8-and-loosely-coupled-ie-lcie.aspx) where the other window or tab is running in a different process, but I haven't personally looked into this.

• Anonymous
  September 20, 2009
  @EricLaw: I see.  The strategy other browsers use here is to keep all the tabs in the same unit of related browsing contexts in the same process (even when they're cross-origin). There are other corner cases you'll get wrong if don't keep these windows in the same process, but I don't know how important they are to compatibility.  For example, imagine reaching into a same-origin subframe of a cross-origin window.

• Anonymous
  September 21, 2009
  @Adam: It's important for LCIE to be able to put a single "browsing context" containing multiple tabs into multiple processes. Remember, the primary goal of LCIE is reliability, so that if one tab crashes, it won't bring down others. We couldn't really achieve that goal if most of the user's active tabs lived within a single process. LCIE has code that works to broker state (E.g. session cookies) across processes in a browser context. The "reaching in to a same-origin subframe" scenario, for instance, ought to work properly. If LCIE didn't broker state, the introduction of that feature would have broken a huge number of sites. That said, beyond postMessage, there are still some corner cases that are impacted by LCIE (e.g. plugins using shared memory with the expectation that all tabs are in the same processes).

• Anonymous
  January 21, 2010
  the localStorage is meant to persist even after you close the browser. but in my case, it is only persisting while the window is open. It is happening in all the browsers. What went wrong? Could you help me out?

• Anonymous
  January 21, 2010
  @Santosh: Unless you've configured to run your browser to clear history on exit, or are running in Private mode, there's no explanation for that. What browsers do you mean when you say "all the browsers"? What does your code look like? Do you have a sample URL?

• Anonymous
  January 21, 2011
  If you want to see these items in action and/or want to test by your own, have a look here http://w3c.html5.free.fr.

• Anonymous
  July 22, 2011
  Any idea if & when is MS going to resolve the postMessage from a popup issue? [EricLaw-MSFT]: Sorry, no, we haven't made any announcements in this area.

• Anonymous
  August 18, 2012
  Does Microsoft have any plans to fix the postMessage issue when it is used across tabs and windows (i.e. the "Call postMessage directly" example from the popup on the test page)?  It's still an issue in IE8, IE9, and even the RTM version of IE10 on Windows 8.

• Anonymous
  August 18, 2012
  @Matt: Not at present.

• Anonymous
  September 19, 2012
  Any idea if and when Microsoft are going to resolve the "message must be a string" issue (you can send an object as a message in Chrome, which is W3C spec) in IE8 and IE9? And how about fixing popups so you don't have to use the (unreliable as being the desired target) window.top rather than window.opener property as the receiving window handle? In other words:    window.opener.postMessage(message, authority); instead of    window.top.postMessage(message, authority);

• Anonymous
  September 19, 2012
  @MrBester: For compatibility reasons, IE8 and IE9 would not be changed as described (e.g. allowing objects to be sent). I assume this was fixed in IE10 based on your question? I'm not sure what "fixing popups" means.