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

On Wed, 02 Feb 2011 23:28:56 +0100, 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.

Hmm. I'm not sure what to think of IndexedDB using window.onerror.  
window.onerror is used for catching JS syntax errors and uncaught  
exceptions in scripts. Also, window.onerror is invoked directly without  
firing an actual event. What's the use case for firing an error event on  
window for IndexedDB?


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

Not really. Workers have their own onerror handler in the worker script  
itself, and if the error is still "not handled", an error event is fired  
on the worker object, but it stops there; an error event is never fired on  
window.

-- 
Simon Pieters
Opera Software

Received on Monday, 7 February 2011 10:23:20 UTC