http://www.w3.org/TR/webstorage/#the-storage-interface says "Values can be any data type supported by the structured clone algorithm." Apparently this was changed in whatwg r3549 <http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2009/002717.html> without anyone noticing. At least <http://stackoverflow.com/questions/2010892/storing-objects-in-html5-localstorage/2010948#2010948> claims that every browser implemented string-only values. A simple testcase is attached, here's an extract: localStorage["test"] = {a:1}; typeof localStorage["test"] == "string" // should be "object" localStorage["test"].a != 1 // should be == 1. I couldn't find anything about this change to structured data on the web, other than people wondering what was the reason for this change. Obviously it would be more convenient for developers if all browsers consistently implemented structured values. Either the spec should be changed to match reality or the browsers should implement structured data.

*** Bug 572474 has been unmarked as a duplicate of this bug. *** because after "Clear Recent History..." sessionStorage keys/values pairs should be removed. If the key does not exist getItem method must return null. Actual values in sessionStorage are replacing by empty strings.

Should we consider WONTFIXing this? I don't think WebKit does this ... and making localStorage more useful seems like a waste of time.

The spec has been changed to string values only. See the w3.org bug, particularly comments 6, 7, 11, and 15 for the rationale.

(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #5) > The spec has been changed to string values only. See the w3.org bug, > particularly comments 6, 7, 11, and 15 for the rationale. For the record, that bug is http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111

For the record, the rationale is "Mozilla (and the other browsers) didn't do it". The spec would change back in a second if this bug was fixed and the feature implemented.

You mean "it would change back in a second if all major browsers, or a significant majority thereof, decided to implement it"?

If this is the resolution so be it, but here's use case for this that I haven't seen considered: the storage event is broadcast to all windows with that origin; this is only widely-implemented standard way to pass messages between windows that don't have references to each other's window object. In this case, localStorage is used as a message queue. IndexDB doesn't appear to have equivalent functionality. This bug caused a bit of pain for me because I read the spec's mention of structured data and assumed my messages would work interchangablely between the storage event and window.PostMessage. OTOH, this functionality would be better suited as extension to PostMessage (giving it some sort of broadcast option) and once SharedWorkers are widely implemented it could be used for this too, albeit as more heavy weight solution.