[Webkit-unassigned] [Bug 149205] New: IndexedDB openKeyCursor() returns primaryKeys in wrong order

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=149205

            Bug ID: 149205
           Summary: IndexedDB openKeyCursor() returns primaryKeys in wrong
                    order
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: nolan at nolanlawson.com

Created attachment 261291
  --> https://bugs.webkit.org/attachment.cgi?id=261291&action=review
Reproducible test case

Let's say you create an objectStore with a primary key and a secondary key, and you insert:

{primaryKey: 'a', secondaryKey: 0}
{primaryKey: 'b', secondaryKey: 0}
{primaryKey: 'c', secondaryKey: 0}

If you then call openKeyCursor() on the secondary index, then the cursor's primaryKeys should be returned in order (since the secondary indexes are all the same).

However, in WebKit nightly 10600.8.9, r189569 I am able to get the cursor to return the primaryKeys in the wrong order, although only after a refresh. It seems like the order of the keys is being determined by the length instead of lexicographic order, but I'm not sure.

I have a reproducible test to demonstrate (also attached to this bug): http://bl.ocks.org/nolanlawson/32daf56e98904562b52d

This bug cannot be reproduced in IE 10, Firefox 40, or Chrome 45. There is a note in the IndexedDB spec explaining this behavior:

> records is always sorted in ascending key order.
> In the case of source being an index, records is secondarily sorted 
> in ascending value order (where the value in an index is the key of 
> the record in the referenced object store). 

Source: http://w3c.github.io/IndexedDB/#h-cursor-iteration-operation

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150916/cdeaf182/attachment-0001.html>