IndexedDB: ambiguity around IDBTransaction.error

I have found what feels like an ambiguity in the spec around
IDBTransaction.error and when it is available.

In particular, the spec says:

> When the done <http://www.w3.org/TR/IndexedDB/#dfn-request-done> flag is
> true, getting this property *must* return the error of the request that
> caused the transaction <http://www.w3.org/TR/IndexedDB/#dfn-transaction> to
> be aborted. [...] When the done<http://www.w3.org/TR/IndexedDB/#dfn-request-done> flag
> is false, getting this property *must* throw a DOMException of type
> InvalidStateError.


The ambiguity here is that the 'done flag' is technically something that
resides on the request, not the transaction. After the transaction itself
is complete, the 'error' attribute should be the error that caused the
transaction to abort, if any. So the question is, which 'done' flag does
this correspond to - the done flag on the current request, the done flag on
the request that caused the abort, or some other 'done' state about the
transaction itself.

An example:

transaction = ...
transaction.objectStores("foo").put(badValue).onerror = function(event) {
  // can I access transaction.error here?

  // the request has its own error though.
  requestError = event.target.error;

  transaction.objectStores("foo").put(goodValue).onsuccess =function(event)
{
  // can I access transaction.error here? If so, is it requestError, or is
it null?
  }
}

transaction.objectStores("foo").put(goodValue).onsuccess =

As a consumer of this interface, I'd expect the transaction's error
property to be set early - i.e. available as soon as the error handler
fires, above, and then I'd expect it to remain unchanged for the duration
of the rest of the transaction. But I can see arguments against that. For
instance, what happens if preventDefault() is called? we need to avoid
setting the error in that case.. I think. So that would argue for some kind
of 'done' flag / state for the transaction itself.

Thoughts?

Alec