Re: IndexedDB: negative zero as keys/values

On Friday, September 16, 2011, Joshua Bell <jsbell@chromium.org> wrote:
> 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 (
http://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data),
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)
> e.g.
>        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.
http://wiki.ecmascript.org/doku.php?id=harmony:egal
> 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?

Given that -0 === 0 in JS, and that IEEE754 defines that -0 is equal to 0, I
think we should treat them as the same key.

As to what to return for a key when -0 was originally used, I don't really
have a strong opinion.

/ Jonas