Re: [Bug 7104] New: Disagreement on handling of null value for localStorage.setItem()

On Tue, Jul 14, 2009 at 12:41 PM, <bugzilla@farnsworth.w3.org> wrote:

> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7104
>
>           Summary: Disagreement on handling of null value for
>                    localStorage.setItem()
>           Product: WebAppsWG
>           Version: unspecified
>          Platform: Macintosh
>        OS/Version: MacOS X
>            Status: NEW
>          Severity: normal
>          Priority: P2
>         Component: Web Storage
>        AssignedTo: ian@hixie.ch
>        ReportedBy: brett@python.org
>         QAContact: member-webapi-cvs@w3.org
>                CC: mike@w3.org, public-webapps@w3.org
>
>
> Created an attachment (id=718)
>  --> (http://www.w3.org/Bugs/Public/attachment.cgi?id=718)
> 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 brought this issue up on WhatWG.org a while ago.  I'm pretty sure Safari
is right.


> 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.


Exactly.  Someone should file a bug on Firefox.