Description

stelar7

opened on Apr 1, 2025

Issue body actions

asynchronously execute a request takes a source object.

In most places this refers to an IDBObjectStore, IDBIndex, or IDBCursor. (handle objects)
However, in IDBCursor::continue step 11, it seems to refer to the "internal" objects (Object Store, and Index)
Since JS is never exposed to "internal" types, having them there seems very odd.

Is this a typo (this’s source -> this) for some of the IDBCursor methods? (advance, continue, continuePrimaryKey)

Or should the methods that create an IDBCursor pass a different object instead?
i.e IDBObjectStore::openCursor creates one with this's object store, which would be an "internal" object

Activity

1. inexorabletash commented on Apr 3, 2025

   

   inexorabletash

   on Apr 3, 2025

   Member

   More actions

   I suspect the text around sources probably predates splitting the concepts of the abstract "internal" object store/index sitting in the database from the handles (which map 1:1 with the JS-exposed interfaces). So yes, we would want to fix this.

   From looking at how the source is used (namely, "Let transaction be the transaction associated with source.") a request's source should be a handle object rather than the internal object, since handle objects have associated transactions. Also, ultimately calling request.source is going to give back an IDBObjectStore, IDBIndex, or IDBCursor so in the former two cases it needs to be the handle object. To do so, we probably need to do a more intrusive change where either (a) the cursor's source is a handle object (and do the extra hop to get from the handle to the internal object), or (b) the cursor holds onto both a handle source and an internal source.

   For cursors we need to look carefully at the tests and the behaviors of shipping implementations because there are two cases:

   • For operations that create or advance the cursor (openCursor, continue, continuePrimaryKey, advance) I believe the source is intended to be the IDBObjectStore / IDBIndex
   • For operations that add work in the transaction (delete, update) I believe the source is intended to be the IDBCursor.

   ... but I don't remember very well. Anyway, some archaeology is needed here. PR's welcome!
2. inexorabletash

   added

   needs-pr

   on Apr 3, 2025
3. inexorabletash

   closed this as completedin #455on May 5, 2025
4. inexorabletash

   added a commit that references this issue on May 5, 2025

   Add handle to cursor to avoid exposing internal state to script (#455)

   This issue will close once commit 812ee6f is merged into the 'main' branch.

   812ee6f
5. aarongable

   added a commit that references this issue on May 8, 2025

   [IndexedDB] Add more cursor request source WPT coverage

   37a90ff
6. chromium-wpt-export-bot

   added 2 commits that reference this issue on May 8, 2025

   [IndexedDB] Add more cursor request source WPT coverage

   9bcbe33

   [IndexedDB] Add more cursor request source WPT coverage

   8ff5176
7. lando-worker

   added a commit that references this issue on May 14, 2025

   Bug 1965765 [wpt PR 52432] - [IndexedDB] Add more cursor request sour…

   642b64f
8. moz-v2v-gh

   added a commit that references this issue on May 15, 2025

   Bug 1965765 [wpt PR 52432] - [IndexedDB] Add more cursor request sour…

   1b5b681
9. gecko-dev-updater

   added 3 commits that reference this issue on May 16, 2025

   Bug 1965765 [wpt PR 52432] - [IndexedDB] Add more cursor request sour…

   56c0b4b

   Bug 1965765 [wpt PR 52432] - [IndexedDB] Add more cursor request sour…

   3d0d0f4

   Bug 1965765 [wpt PR 52432] - [IndexedDB] Add more cursor request sour…

   4504884

Issue actions