Original test: http://mxr.mozilla.org/mozilla2.0/source/dom/indexedDB/test/test_indexes.html?force=1 This is an adapation of part of a test from Mozilla's IndexedDB test suite. It creates an object store with several rows, creates indexes on each key, and iterates through an index key cursor from end to start using the PREV_NO_DUPLICATE flag. Of two records that contain the same key in the index, the cursor chooses the wrong one. Or, at least, a different one than Mozilla chooses. In the attached test case, Joe and Pat have the same height. In an index key cursor on the 'height' key with a null key range, starting at the end and moving backward with PREV_NO_DUPLICATE, the test expects to find Joe, but WebKit finds Pat instead. Similar to bug 60746, and I suspect the fix is similar (but in a different method, thus a separate bug report).
Created attachment 93442 [details] test case
Created attachment 93904 [details] Patch
Comment on attachment 93904 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=93904&action=review > LayoutTests/storage/indexeddb/index-cursor.html:27 > + "the BIGGEST string" Why did these get changed?
Who should review this change?
This patch is old, and doesn't apply anymore since the SQLite back-end is gone, but it would be nice to get the test. I'm not sure what the correct behavior is here. For PREV_NO_DUPLICATE, the spec says: "[...] this cursor should yield all records, not including duplicates and its direction is monotonically decreasing order of keys. For every key with duplicate values, only the first record is yielded." What does *first record* mean in this context? The first record that is found when traversing the records in monotonically decreasing order of keys, or the first record as in lowest record? This test seems to expect the latter, but we do the former.
Oh, I see this is the same discussion as on Bug 60746. It seems this was discussed here: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0480.html
Consensus on the list: http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0599.html Summary: PREV_NO_DUPLICATE should end up returning the same set of entries as NEXT_NO_DUPLICATE, just in reverse order. So PREV_NO_DUPLICATE should return the lowest (by primary key) of the duplicate entries.
Comment on attachment 93904 [details] Patch Rejecting attachment 93904 [details] from commit-queue. Failed to run "['/mnt/git/webkit-commit-queue/Tools/Scripts/webkit-patch', '--status-host=queues.webkit.org', '-..." exit_code: 2 Last 500 characters of output: fset -2 lines). patching file LayoutTests/storage/indexeddb/index-cursor-expected.txt patching file LayoutTests/storage/indexeddb/index-cursor.html Hunk #1 succeeded at 15 (offset -2 lines). patching file LayoutTests/storage/indexeddb/mozilla/index-key-prev-no-duplicate-expected.txt patching file LayoutTests/storage/indexeddb/mozilla/index-key-prev-no-duplicate.html Failed to run "[u'/mnt/git/webkit-commit-queue/Tools/Scripts/svn-apply', u'--reviewer', u'Darin Adler', u'--force']" exit_code: 1 Full output: http://queues.webkit.org/results/10996152
the implementation is being done in another bug, both index and objectStore in the same plcae *** This bug has been marked as a duplicate of bug 60746 ***