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

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?
Thanks,

Israel

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