[Webkit-unassigned] [Bug 59822] New: IndexedDB does not update r/w index cursors that are mutated during iteration

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Apr 29 13:25:32 PDT 2011


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

           Summary: IndexedDB does not update r/w index cursors that are
                    mutated during iteration
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P3
         Component: New Bugs
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pilgrim at chromium.org
                CC: fishd at chromium.org, tony at chromium.org,
                    hans at chromium.org, dgrogan at chromium.org,
                    pilgrim at chromium.org


Original test: http://mxr.mozilla.org/mozilla2.0/source/dom/indexedDB/test/test_cursor_mutation.html?raw=1
Ported test: see attachment

The scenario here is that you have an object store with data in it, and an index on one of the fields. (In the attached test, the index is an alphabetical index of first names.) You open a read/write transaction and use it to open a cursor on the index. While iterating through the cursor (in alphabetical order), you mutate the object store to add another row whose values would not yet have shown up in iteration.

Expected result: the index cursor should automatically update to include the new row when it eventually comes up in the alphabetical order (of the index). The mutation occurs before the added name would have appeared in the cursor iteration, thus the iteration should eventually find it.

Actual result: WebKit's behavior is to skip over the row that was added during iteration. Iteration of the index cursor continues in the expected (alphabetical) order through the original data in the object store, but the added row is never found.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list