W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2012

[IndexedDB] Implementation Discrepancies on 'prevunique' and 'nextunique' on index cursor

From: Israel Hilerio <israelh@microsoft.com>
Date: Wed, 3 Oct 2012 01:34:53 +0000
To: "public-webapps@w3.org" <public-webapps@w3.org>
CC: Victor Ngo <vicngo@microsoft.com>
Message-ID: <86D991F0ED8B1B47A81B863E89FB565C186A7485@BY2PRD0310MB354.namprd03.prod.outlook.com>
We noticed there is consistent behavior between FF v.15.0.1 and Chrome v.24.0.1284.0 canary that we believe is a bug when dealing with both 'prevunique' and 'nextunique'.  Below is what we're seeing using the following site http://jsbin.com/iyobis/10/edit

For the following data set (keypath = 'id')
{id:1, a: 'foo' };
{id:2, a: 'bar' };
{id:3, a: 'foo' };

When we open the cursor with prevunique and nextunique, on an index on 'a' using IDBKeyRnage.only('foo') we get the following record back:
{id:1, a: 'foo' };

For the data above, it seems like there should be different return values for prevunique and nextunique based on the definitions on the spec.

Our expectation was that for prevunique we would get the following record:
{id:3, a: 'foo' };
The reason being that the bottom of our index list starts with id:3.

And for nextunique we would get the following record:
{id:1, a: 'foo' };
The reason being that the top of our index list starts with id:1.

Since we're seeing this behavior in both browsers (FF and Canary) we wanted to validate that this is not by design.

Can you confirm?

Received on Wednesday, 3 October 2012 01:35:31 UTC

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