W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

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

From: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 2 Feb 2011 15:19:18 -0800
Message-ID: <AANLkTinB3qO0VoSdycf0ZuZY3ycGnXYcZK0k9+w=xtRC@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: public-webapps@w3.org
I don't know much about window.onerror (I'm finding out what the story is in
WebKit), but overall sounds fine to me.

What about complete events?  Should we make those non-bubbling as well?

J

On Wed, Feb 2, 2011 at 2:28 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Feb 2, 2011 at 2:10 PM, Jeremy Orlow <jorlow@chromium.org> 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 23:20:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT