"If an exception was propagated out from any event handler" is not a thing

[annevk]

While reading through #87 I found Indexed DB has been monkey patching DOM as well with something that is not supported by the event dispatch algorithm. The event dispatch algorithm handles its own exceptions and reports them to window.onerror. It seems you're trying to hook into that somehow.

[annevk]

In particular in 7.5 of https://w3c.github.io/IndexedDB/#upgrade-transaction-steps.

[inexorabletash]

Nicely spotted. This has been in the spec since forever (early iterations of v1) and behavior is consistent across browsers, so we may need another hook unless someone can come up with a clever way of describing this.

(Hopefully there aren't too many more monkey patches lurking?).

[annevk]

Does the error still go to window.onerror? We don't really have a concept of UA-event-listeners, so I suspect we need some kind of hook.

[inexorabletash]

I haven't spec'd window.onerror integration yet (see #49) - it's implemented in Firefox but not Chrome. (I hit a performance regression whenever I try, and then get distracted by other shiny things.) Since IDB is exposed in workers there was apparently some trickiness on the spec side too, but that may have been sorted out.

But in Firefox, yes - an error from a request that does not have preventDefault() called on the event causes the transaction to abort and propagates to window.onerror, but by the time it hits the global error handler it's too late to "preventDefault()" and stop the transaction from aborting.

[annevk]

If you call preventDefault() and then throw, it would not abort? That doesn't seem to be specified. But I guess the cleanest integration would be to change how dispatch works. Either we need to return more information than just a boolean, or you need to pass something in that gets modified (which is somewhat ugly I think, but okay).

[inexorabletash]

Sorry, was mostly asleep - I was thinking about the error event case, not the exception case. I'll do some testing about preventDefault() vs. throwing and report back.

And either approach (additional return value or an "out" parameter or callback) is fine with me.

[inexorabletash]

Oh yes, needed to follow up here.

PR for tests added. As expected, preventDefault() doesn't change behavior. And behavior is the same across event handlers/listeners, and (in the case of error) how far the event has bubbled.

[annevk]

I created a hook for the "dispatch" algorithm that you can use. (And review!)