This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We talked about this for a while at TPAC. Here's what I think we agreed upon at the time: * All events should propagate from the IDBRequest to the IDBTransaction to the IDBDatabase. * For error events, preventDefault must be called in order to avoid a transaction aborting. (When you use onerror, you'd of course use false to do so.) * If you throw within an event handler, the transaction will abort. (Catch errors that you don't want to implicitly abort the transaction.) * The success event will be non-bubbling (because having onsuccess on IDBTransaction and IDBDatabase would be confusing). * The error event should be added to IDBTransaction and IDBDatabase and should bubble. * createObjectStore should remain sync and simply abort the transaction on errors (which are pretty much constrained to quota and internal errors). * createIndex is the same, except that indexes with a uniqueness constraint and existing data that doesn't satisfy it will present another (and more common) case that'll cause the transaction to abort. The spec should have a red note that reminds people of this.
*** Bug 10302 has been marked as a duplicate of this bug. ***
*** Bug 10303 has been marked as a duplicate of this bug. ***
More details from Jonas: Actually, I was proposing something entirely different. IDBRequest should look like this: interface IDBRequest : EventTarget { attribute any result; attribute unsigned long errorCode; attribute DOMObject source; attribute IDBTransaction transaction; const unsigned short LOADING = 1; const unsigned short DONE = 2; readonly attribute unsigned short readyState; attribute Function onsuccess; attribute Function onerror; }; "success" and "error" events are plain Event objects, i.e. no indexedDB-specific properties. The advantage of this is: 1. Request objects are actually useful as representing the request. Consumers of a request can check what the readystate is and either get the .result or attach a event listener as appropriate. (As things stand now you can't really rely on .readyState. The only thing it tells you is if you got to the request too late or not. If you risk getting there too late you better rewrite your code) 2. Easier to implement a promises-style API on top of indexedDB. 3. More similar to for example XMLHttpRequest The downside is: 1. Have to use a bigger syntax to get to the result. "event.result" vs. "event.target.result".
Note that we also agreed that .result and .errorCode should raise before the readyState is DONE and should return undefined and 0 (respectively) when it is DONE but they're not applicable.
Also, the way the spec is written, it seems as though we're saying events should be fired synchronously in some cases (like when a transaction is aborted). We should fix that too.
This should now be FIXED!