This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Created attachment 718 [details] test page that shows what localStorage.getItem() thinks null should be In Safari 4, if you use null as a value when setting a new key it will end up returning the string "null". But in Firefox 3.5, you get back null itself. I have attached a dead-simple HTML file that shows the differences when run in the two browsers. Not sure who is right since the spec says a DOMString is expected and I am not sure if null is considered a valid DOMString. And in both browsers you end up with a key being set. While in Safari that makes sense since you are getting back a string, but in Firefox that's confusing as the value for the key is the same as the value used to signify that no value exists for the key. That means in Firefox the only way to know that the key is actually set explicitly to null is to iterate through all the keys using localStorage.key() to try to see if the key has actually been given a value.
I brought this up on WhatWG a while ago. I believe it was agreed that Firefox's implementation goes against the spec.
(In reply to comment #1) > I brought this up on WhatWG a while ago. I believe it was agreed that > Firefox's implementation goes against the spec. > Best I could find was http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014383.html which ended with someone believing that Firefox is wrong and Safari is right, but no definitive answer.
I apologize...I must have been remembering incorrectly. I couldn't even find any mentions of any such message in my email archive, which further confounds me. So yes, I suppose it is good to double check and perhaps have specific language in the spec to settle the issue once and for all. :-) From my reading, the Safari way of doing things is definitely the correct one. The rational is essentially what you already mentioned, Brett. If not, a .contains method should be added...but writing code for such an interface seems cumbersome.
Although my opinion counts for squat, I do agree with Safari's behavior as well. Coercion of an object to a string is common enough in JS that it is reasonable to have null coerced. It did catch me by surprise that it did that, but I chalk that up to lack of JS experience on my part. And once an official decision is made on this I will report the proper behavior to the right browser folks.
I propose to make the spec just use the default behaviour specified by Web IDL.
Could you tell me what that means, Ian? I am writing a localStorage wrapper to deal with browser incompatibilities and add some helper functions and I would like to keep the wrapper agreeing with the spec.
I'm not 100% sure, as this has changed a few times, but it appears: http://dev.w3.org/2006/webapi/WebIDL/#TreatNullAs ...that it means that null and undefined, when passed to methods accepting DOMStrings, treat them as the strings "null" and "undefined" respectively.
Thanks for the clarification, Ian! That's what I figured; just pass all key/value arguments through String. That leaves Firefox 3.5 incompatible in this instance and (I believe) a bug report has been sent in. And as an aside for anyone curious how FF 3.5 and Safari 4 are incompatible with the spec so far, both do not implement ``localStorage.key(localStorage.length)`` properly as they both throw an exception instead of returning null. I reported the appropriate bugs. Otherwise they seem to be following the spec.