This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12111 - spec for Storage object getItem(key) method does not match implementation behavior
Summary: spec for Storage object getItem(key) method does not match implementation beh...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Web Storage (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-17 15:17 UTC by Michael[tm] Smith
Modified: 2011-08-04 06:50 UTC (History)
11 users (show)

See Also:


Attachments

Description Michael[tm] Smith 2011-02-17 15:17:57 UTC
http://dev.w3.org/html5/webstorage/#dom-storage-getitem says that "The getItem(key) method must return a structured clone of the current value associated with the given key." but all browsers I've tested return a string representation of the value instead.
Comment 1 Ian 'Hixie' Hickson 2011-06-01 17:39:04 UTC
This is just because the spec added this feature after the last round of implementations, but I'll mark this REMIND so I can look into it again in a few months and see where we stand.
Comment 2 Philippe Le Hegaret 2011-06-01 18:12:35 UTC
A spec that does not match implementation behavior doesn't seem useful to me. Is there any reason to think that the implementations will change?
Comment 3 Aryeh Gregor 2011-06-01 20:19:01 UTC
I seriously doubt the specced behavior is web-compatible.  For instance, I myself just discovered this when trying to store booleans in localStorage, and worked around it by testing localStorage["foo"] != "false".  If localStorage["foo"] = false suddenly actually sets it to false instead of "false", this will break.
Comment 4 Arthur Barstow 2011-06-02 11:30:08 UTC
Aryeh, PLH - please make a concrete proposal (e.g. diff) that addresses your comments.
Comment 5 Philippe Le Hegaret 2011-06-02 12:31:42 UTC
here is how the change should look like I think:

[[

interface Storage {
  [...]
  getter DOMString getItem(in DOMString key);
  setter creator void setItem(in DOMString key, in DOMString value);
  [...]
};

[...]

The getItem(key) method must return the current value associated with the given key. If the given key does not exist in the list associated with the object then this method must return null.

The setItem(key, value) method must set the value of a given key. If this raises an exception, then the exception must be thrown and the previous value associated with the given key is left unchanged.

]]

For forward compatibility purposes, I would not change the types of oldValue and newValue in the StorageEvent interface. In practice, those will be DOMString since that's the only thing one can store, but this could change in the future if we add a getValue and a setValue methods to the Storage interface with the type any.
Comment 6 Kyle Huey 2011-06-02 20:55:16 UTC
I talked with some other folks at Mozilla (Jonas Sicking and Ben Turner) about this and the general feeling seems to be that we're not particularly interested in implementing structured clones for localStorage values.  In addition to the web compat concerns, improving localStorage doesn't seem to be a good investment of time and resources, and runs the risk of encouraging more developers to use an API we'd rather they didn't.

The isn't an official statement that we won't implement it (it's still open in our bug tracker at https://bugzilla.mozilla.org/show_bug.cgi?id=538142), and some other Mozilla people might disagree with me here.
Comment 7 Jeremy Orlow 2011-06-03 08:47:14 UTC
Kyle's comment also applies to Chromium.  (Including the fact that some folks may disagree, but I believe it's the predominate opinion of the developers working on it.)
Comment 8 Alexey Proskuryakov 2011-06-03 17:12:44 UTC
I don't think that it matters too much whether developers manually serialize to JSON or the engine does that for them.

Having engine help would be good for consistency of the platform, as you should be able to assign persistent properties to localStorage and sessionStorage objects exactly like you do it for any JavaScript object. There is no technical reason to require the quirk of only allowing string properties, and I would personally like to have arbitrary properties implemented in WebKit eventually.
Comment 9 Aryeh Gregor 2011-06-05 18:20:19 UTC
(In reply to comment #6)
> I talked with some other folks at Mozilla (Jonas Sicking and Ben Turner) about
> this and the general feeling seems to be that we're not particularly interested
> in implementing structured clones for localStorage values.  In addition to the
> web compat concerns, improving localStorage doesn't seem to be a good
> investment of time and resources, and runs the risk of encouraging more
> developers to use an API we'd rather they didn't.

What should they use instead?  localStorage serves a very useful purpose as a simple persistent key-value store.  If it has problems, like locking or synchronousness, we need to either fix them or come up with a tenable replacement.  The only one I'm aware of in the works is IDB, which doesn't even come close to being simple enough to be a localStorage replacement.
Comment 10 Jeremy Orlow 2011-06-05 18:35:49 UTC
(In reply to comment #9)
> (In reply to comment #6)
> > I talked with some other folks at Mozilla (Jonas Sicking and Ben Turner) about
> > this and the general feeling seems to be that we're not particularly interested
> > in implementing structured clones for localStorage values.  In addition to the
> > web compat concerns, improving localStorage doesn't seem to be a good
> > investment of time and resources, and runs the risk of encouraging more
> > developers to use an API we'd rather they didn't.
> 
> What should they use instead?  localStorage serves a very useful purpose as a
> simple persistent key-value store.  If it has problems, like locking or
> synchronousness, we need to either fix them or come up with a tenable
> replacement.  The only one I'm aware of in the works is IDB, which doesn't even
> come close to being simple enough to be a localStorage replacement.

Fixing local storage has been discussed ad nauseum. It can only be done with major backwards incompatible changes. We've also talked about creating a new API and the sentiment is that we already have 3. At this point, more churn is probably not the right answer. Getting one API (IndexedDB) right, letting library developers (like lawnchair) fill in the gaps in the mean time, and making an educated decision in the future seems like a much better answer.
Comment 11 Adrian Bateman [MSFT] 2011-06-06 19:25:53 UTC
(In reply to comment #10)
> Fixing local storage has been discussed ad nauseum. It can only be done with
> major backwards incompatible changes. We've also talked about creating a new
> API and the sentiment is that we already have 3. At this point, more churn is
> probably not the right answer. Getting one API (IndexedDB) right, letting
> library developers (like lawnchair) fill in the gaps in the mean time, and
> making an educated decision in the future seems like a much better answer.

I agree. This was raised back in November after TPAC:
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0773.html
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0798.html

Our plans have not changed: We have no plans to change the behaviour of Web Storage in IE to support structured clones. We believe IndexedDB represents a better mechanism for storing structured data in the Web Platform.
Comment 12 Anne 2011-06-20 10:44:01 UTC
I was asked to state Opera's position here. We do not feel strongly either way. If we indeed want people to move away from this API it would probably be better to keep it string-based so no extra implementation cycles are needed for a feature that is to be avoided.
Comment 13 Aryeh Gregor 2011-06-20 14:24:52 UTC
What's Opera's position on the compat implications?
Comment 14 Anne 2011-06-20 14:28:18 UTC
Making that transition is doable probably, but it is unlikely we will get that far seeing that no implementor apart from ap is really interested.
Comment 15 Ian 'Hixie' Hickson 2011-08-04 06:50:44 UTC
Since browser vendors are no longer interested in using Web Storage for structured data, I've moved the spec back to just strings.
Comment 16 contributor 2011-08-04 06:50:58 UTC
Checked in as WHATWG revision r6364.
Check-in comment: Remove the structed data support from Web Storage.
http://html5.org/tools/web-apps-tracker?from=6363&to=6364