support structured data (not just strings) in localStorage/sessionStorage

VERIFIED INVALID

Status

()

Core
DOM
VERIFIED INVALID
8 years ago
6 years ago

People

(Reporter: Nickolay_Ponomarev, Unassigned)

Tracking

({html5, testcase})

Trunk
html5, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Created attachment 420308 [details]
testcase

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.
(Reporter)

Updated

7 years ago
Depends on: 550275

Updated

7 years ago
Duplicate of this bug: 572474

Comment 2

7 years ago
*** 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.

Updated

7 years ago
Duplicate of this bug: 572474
Should we consider WONTFIXing this?  I don't think WebKit does this ... and making localStorage more useful seems like a waste of time.

Updated

6 years ago
The spec has been changed to string values only.  See the w3.org bug, particularly comments 6, 7, 11, and 15 for the rationale.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX

Comment 6

6 years ago
(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"?

Comment 9

6 years ago
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.

Updated

6 years ago
Status: RESOLVED → VERIFIED
Resolution: WONTFIX → INVALID
You need to log in before you can comment on or make changes to this bug.