Created attachment 261291 [details] 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
This test case works in ToT - Please try in the latest WebKit nightly.
Confirmed fixed in WebKit Nightly. Thank you!