[w3c/IndexedDB] Cursor property updating precedes success event (#340)

When a cursor advances, say via `continue()` the [steps](https://w3c.github.io/IndexedDB/#dom-idbcursor-continue) use the [iterate a cursor](https://w3c.github.io/IndexedDB/#iterate-a-cursor) operation and the [asynchronously execute a request](https://w3c.github.io/IndexedDB/#asynchronously-execute-a-request) steps. This means:

* The operation gets queued
* The operation eventually runs 
* The operation updates the cursor's properties (key, value, got value flag, etc)
* The steps queue a task to fire a success event

That means the cursor properties update before the event fires, which means polling could see the properties change earlier. I think this is what the obscurely worded #339 is hinting at.

Chrome doesn't implement it this way - properties are not visible on the IDBCursor until the event fires. They're applied synchronously just before the event is dispatched.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/340