W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

IndexedDB: negative zero as keys/values

From: Joshua Bell <jsbell@chromium.org>
Date: Fri, 16 Sep 2011 15:23:17 -0700
Message-ID: <CAD649j4wq=JdtGr2zWr=znDmi-cLdkbNToVu-ntS48_xMkWTOQ@mail.gmail.com>
To: public-webapps@w3.org
There appears to be a minor edge case in the IndexedDB draft (
http://www.w3.org/TR/IndexedDB) - and inconsistencies between
implementations - for the ECMAScript "negative zero" number value. While the
other numeric edge cases - NaN and +/-Infinity - are called out explicitly
in the draft when discussing keys, negative zero is not. The intended
handling of -0 in values could, in theory, be covered by the HTML5
structured clone algorithm (
but it also has no explicit mention of -0.

In Chrome 14, -0 and 0 are treated as the same key, and -0 values are read
back as 0. In Firefox 6, -0 is preserved as a value, but 0 and -0 are
treated as the same key. (I have not tested IE10)

       store.put(-0, 'key for -0');
       store.put('value for key -0', -0);
       store.put('value for key 0', 0);

       store.get('key for -0').onsuccess = function (e) {
         assertEqual(-0, e.target.result, '-0 as a value'); };

       store.get(-0).onsuccess = function (e) {
         assertEqual('value for key -0', e.target.result, '-0 as a key'); };

.... for some suitably -0-aware assertEqual comparison - e.g.

This will "fail" in both cases in Chrome 14, and "fail" in the second case
only in Firefox 6.

In other words, in at least these two current implementations, -0 is treated
as the same key as 0. However, the two current implementations disagree
about storing/retrieving -0 values.

Should the draft codify the handling of -0 in keys? And is the handling of
-0 in values properly deferred to the structured clone algorithm?

-- Josh
Received on Friday, 16 September 2011 23:46:49 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:34 UTC