localStorage setItem converting value argument to string before saving

• Component: JavaScriptCore
• Status: RESOLVED INVALID

[David Hong]

According to http://dev.w3.org/html5/webstorage/#the-storage-interface - Storage.setItem is defined this way:

setter creator void setItem(in DOMString key, in any data);

However, Safari 5 / Chrome 5 converts argument data to string before storing, thereby producing some unexpected errors. For example:

// let's store a boolean value
window.localStorage.setItem('a', true);

// typeof returns string
typeof window.localStorage.getItem('a');

// equality does not work
window.localStorage.getItem('a') == true; //evaluates to false

Is this the correct behaviour or will this be fixed? I think this is a bug?

[Jeremy Orlow]

The spec is detached from reality.  It was added to the spec without any browser vendor voicing any intention to implement it.  Even today, I'm not aware of any other browser that's implemented anything other than strings.  If anything, someone should probably bring this up on WhatWG and have the text removed from the spec until someone plans on implementing it.

[David Hong]

I am not really sure as to how I can bring this up to those who work on it; however I did what I can by posting a post on the WhatWG forum: http://forums.whatwg.org/viewtopic.php?p=6053#6053

Thanks for clarifying Jeremy. I'll keep my eye on this and beg/harass/ask/annoy those who can put a conclusion to this.

[Brady Eidson]

Actually, I thought we had a bug on implementing the structured clone algorithm for Storage APIs.

I certainly think it would be good to implement, and it shouldn't even be difficult...

[David Hong]

(In reply to comment #3)
> Actually, I thought we had a bug on implementing the structured clone algorithm for Storage APIs.
> 
> I certainly think it would be good to implement, and it shouldn't even be difficult...

If this is a bug, I think it would be extremely useful and helpful if this was fixed or addressed sometime soon. The general gist I am getting is that DOM Storage API is becoming popular very fast.

If people start implementing DOM Storage logic based on key/value (string/string) pair then future API modifications could be harder to maintain for web-application developers.

At the same time.. How to get attention of other browser vendors in this regard?

[Jeremy Orlow]

(In reply to comment #4)
> (In reply to comment #3)
> > Actually, I thought we had a bug on implementing the structured clone algorithm for Storage APIs.
> > 
> > I certainly think it would be good to implement, and it shouldn't even be difficult...
> 
> If this is a bug, I think it would be extremely useful and helpful if this was fixed or addressed sometime soon. The general gist I am getting is that DOM Storage API is becoming popular very fast.

I'd say that's fairly true.  At the same time, I'm not sure it's a good thing or something we want to encourage.  LocalStorage is either going to be racy or limit concurrency by design.  There's likely no way for UAs to work around this.

> If people start implementing DOM Storage logic based on key/value (string/string) pair then future API modifications could be harder to maintain for web-application developers.

This change will be nearly backwards compatible.  The only way you could get in trouble is if you assume .getItem() is going to return a string (even though what you passed to .setItem() is not).  ...which is a bit worrisome, even if we made the change now (there are already a lot of people using it)...hm...

> At the same time.. How to get attention of other browser vendors in this regard?

Not sure.  File bugs and poke on mailing lists?


Btw, implementing this would be pretty easy for any V8+WebKit since we already have a way to get a string that represents a serialized script value (which could then be stored in SQLite).  JSC's serialized script value does not, however, have this ability.  So most of the work involved would be implementing that.

(If anyone is doing this, I'd like to encourage you to look at how the JSC and V8 versions of serialized script value could be factored together.  The JSC/V8 specific method calls are very similar, so I doubt there's a reason we need two completely different tree crawlers and wire formats.)

[David Hong]

(In reply to comment #0)
> // let's store a boolean value
> window.localStorage.setItem('a', true);
> 
> // typeof returns string
> typeof window.localStorage.getItem('a');
> 
> Is this the correct behaviour or will this be fixed? I think this is a bug?

It seems like the new draft of the Web Storage API has changed to conform to this behaviour. Although it is still in DRAFT, it is worth mentioning.

See: http://dev.w3.org/html5/webstorage/#storage-0

[Alexey Proskuryakov]

See <http://www.w3.org/Bugs/Public/show_bug.cgi?id=12111> for the spec discussion.

[Ian 'Hixie' Hickson]

(In reply to comment #6)
> 
> It seems like the new draft of the Web Storage API has changed to conform
> to this behaviour. Although it is still in DRAFT, it is worth mentioning.

It's not a draft, it's a standard:
http://www.whatwg.org/specs/web-apps/current-work/complete/webstorage.html#dom-storage-getitem

But yes, the spec was changed because nobody was interested in implementing the cloning behaviour. Web Storage is now strings-only.

[David Hong]

Comment #8 invalidates this bug report.

I think we can finally rest this case. The last draft linked by W3C in Last Call action: http://www.w3.org/TR/2011/WD-webstorage-20110901/