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.
Cross-browser remarks: Firefox 3.5.3 and Safari 4.0.2 had no problem with scenarios #2, #3. Opera 10 and Chrome 184.108.40.206 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.