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

On Mon, Feb 14, 2011 at 12:06 AM, Simon Pieters <simonp@opera.com> wrote:
> On Mon, 07 Feb 2011 18:15:04 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Mon, Feb 7, 2011 at 2:22 AM, Simon Pieters <simonp@opera.com> wrote:
>>>
>>> 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.
>>
>> Not just syntax errors. At least in firefox it also fires for uncaught
>> exceptions.
>
> That's what I said. :-)

Oops, my bad :-)

>> So basically we fire all javascript errors which goes unhandled by the
>> page (there is no way to handle syntax errors so they always goes
>> unhandled). That is very much the case here, however since the error
>> reporting must be asynchronous we report it using a event rather than
>> an exception.
>>
>>> What's the use case for firing an error event on window for IndexedDB?
>>
>> What is the use case for error events? I've always thought of it as a
>> choke point where pages can catch JS errors and either display to the
>> user or report back to the server for debugging. If that is the case
>> then this is just another case where errors can arise.
>>
>> Do you have another use case in mind?
>
> There are lots of errors in the Web platform that are not reported to
> window.onerror:
>
> <link>
> <style>
> <script>
> <img>
> <object>
> <video>
> <source>
> <track>
> <input>
> ApplicationCache
> Worker
> SharedWorker
> EventSource
> WebSocket
> <frame>
>
> Should any of those also fire an event to window.onerror as their error
> event's default action? All of them?
>
> What I'm trying to do is to get some consistency so the Web platform doesn't
> appear so designed by committee where half the errors are reported to
> window.onerror and the other half not. It makes stuff harder to learn.

In many of these cases other things than programming errors are likely
the cause of the error. In most of what you are listing network errors
are likely the most common source of errors.

Note again that the IndexedDB errors we are talking about here are
semantically very similar to exceptions. The only reason we're not
making them exceptions is that we can't since exceptions would require
synchronous IO. So I would argue that consistency with exceptions is
more important that consistency with much of what you list above.

That said, maybe we should fire window.onerror for many of the things
that you list above. I'll repeat my question which you left
unanswered:

What is the use case for window.onerror that you had in mind which
would require that we *don't* fire window.onerror for IndexedDB
errors?

/ Jonas

Received on Monday, 14 February 2011 19:00:42 UTC