That sounds good to me. Can you file a bug in our bugzilla?
Though note that the situation is a bit more complex. If a page
expects that a write can fail with a ConstraintError then the page
might want to listen to the error event and call preventDefault() on
But yeah, I agree that listening to the "success" event or a write is
generally not very useful.
On Fri, Mar 16, 2012 at 4:24 AM, Yonathan <yonathan@...> wrote:
> I’m concerned that people will listen to IDBRequest’s “success” event
> to notify when an add or put has been successfully written. For
> example, the “Using IndexedDB” article recommends, “The first thing
> you'll want to do with almost all of the requests you generate is to
> add success and error handlers:” Instead, as far as I can tell,
> success listeners should only be added to read requests (get, count,
> and openCursor after each continue and advance), whereas for write
> requests you should almost always listen to the transaction’s
> “complete” event instead. The reason is that after a request succeeds,
> the transaction as a whole may yet fail due to UnknownError, as well
> as abort or an error in a later request on the same transaction if you
> don’t preventDefault(). Should the specification encourage onsuccess
> for reads and oncomplete for writes?
> : https://developer.mozilla.org/en/IndexedDB/Using_IndexedDB >
> Yonathan Randolph