Cursor property updating precedes success event

[inexorabletash]

When a cursor advances, say via continue() the steps use the iterate a cursor operation and the 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.

[asutherland]

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.

This is also how Firefox works. (And it's hard to imagine an implementation that operates using tasks not working this way.)

[inexorabletash]

One possible approach:

• Define IDBCursor to have internal slots [[key]], [[primaryKey]], [[value]]
• Change the key, primaryKey, and value accessors to return the internal slot values
• Remove the Set cursor’s got value flag to true step from iterate a cursor
• Introduce a set of substeps in asynchronously execute a request in the "otherwise" block at the end, before the event is fired:
  • If request's result is a cursor, then:
    • Let cursor be request's result.
    • Set cursor.[[key]] to this's key (and ditto for primaryKey/value)
    • Set cursor's got value flag to true.

(The wording here suffers a bit due to the lack of distinction between the concept-cursor and IDBCursor.)