Re: [Bug 11348] New: [IndexedDB] Overhaul of the event model

On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow <> wrote:
> Just to confirm, we don't want the events to propagate to the window itself,
> right?

Correct. Sort of. Here's what we did in gecko:

The event propagation path is request->transaction->database. This
goes for both "success" and "error" events. However "success" doesn't
bubble so "normal" event handlers doesn't fire on the transaction or
database for "success". But if you really want you can attach a
capturing listener using .addEventListener and listen to them there.
This matches events fired on nodes.

For "abort" events the propagation path is just transaction->database
since the target of "abort" events is the transaction.

So far this matches what you said.

However, we also wanted to integrate the window.onerror feature in
HTML5. So after we've fired an "error" event, if .preventDefault() was
never called on the event, we fire an error event on the window (can't
remember if this happens before or after we abort the transaction).
This is a separate event, which for example means that even if you
attach a capturing "error" handler on window, you won't see any events
unless an error really went unhandled. And you also can't call
.preventDefault on the error event fired on the window in order to
prevent the transaction from being aborted. It's purely there for
error reporting and distinctly different from the event propagating to
the window.

This is similar to how "error" events are handled in workers.

(I think that so far webkit hasn't implemented the window.onerror
feature yet, so you probably don't want to fire the separate error
event on the window until that has been implemented).

I hope this makes sense and sounds like a good idea?

/ Jonas

Received on Wednesday, 2 February 2011 22:29:52 UTC