- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Wed, 2 Feb 2011 15:19:18 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: public-webapps@w3.org
- Message-ID: <AANLkTinB3qO0VoSdycf0ZuZY3ycGnXYcZK0k9+w=xtRC@mail.gmail.com>
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 UTC