Re: [w3c/IndexedDB] Clarify the handling of +0 and -0 in keys (Issue #375)

WebKit does not normalize negative 0, so for the proposed [test](https://chromium-review.googlesource.com/c/chromium/src/+/3700521/2/third_party/blink/web_tests/external/wpt/IndexedDB/key_negative_zero.any.js), here are the failed tests:
FAIL put(v, -0) key should normalize to +0 assert_equals: key should be normalized to +0 expected 0 but got -0
FAIL put(v, -0) / getKey(v, +0) normalization assert_equals: getKey(+0) should see +0 expected 0 but got -0
FAIL put(v, -0) / getKey(v, -0) normalization assert_equals: getKey(-0) should see +0 expected 0 but got -0
FAIL put(v, -0) / getAllKeys() normalization assert_equals: key should be normalized to +0 expected 0 but got -0

Looks like we have a different case than Blink in the no-normalization implementation.

Generally I think the normalization would simplify the spec and implementation, i.e. we can always assume no -0 in keys. But with existing implementation we have, that probably means we need to convert -0 in database to 0 after the spec change. How is Blink going to deal with this? @inexorabletash 

For the test, I think we can add test for extracting key with key path from value (e.g. ensure -0 is converted to 0 in key, but not in value).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/375#issuecomment-1278111454
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/IndexedDB/issues/375/1278111454@github.com>