Re: [IndexedDB] Discrepancies with the Event type of error in section 4.12

On Tue, Apr 26, 2011 at 10:20 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, Apr 25, 2011 at 6:12 PM, Jacob Rossi <jrossi@microsoft.com> wrote:
>> I plan on adding wording to D3E to clarify that DOM event propagation could apply to other tree-like structures (like indexedDB objects) [1].
>>
>> However, I'm not a fan of defining variable behavior for a given event type. Yes, the spec currently does this--but as you accurately point out, just because it was done before doesn't make it right. :-) Most of these inconsistencies in D3E exist to allow for legacy behavior. Take for example, the scroll event (which is the only event in D3E I can think of which has variable bubbling behavior). It's only defined to bubble in certain cases because that's what is (unfortunately) the interoperable behavior.
>>
>> IMO, I think XHR is wrong to overload error like this. There should be a progresserror event--but I suppose that ship has sailed. Alternatively, DOM3 Events could define an additional event type (with a name other than "error") which does bubble. That way dependent specifications have a choice of which behavior to adopt.
>>
>> Going forward, I think we should be consistent in defining the interface, bubbling, and cancelling aspects of an event type cross-specifications. We can't correct the world as it is today, but we shouldn't proliferate the discrepancies. I think it's a complicated developer model to have an event bubble only in certain scenarios.
>
> I agree consistency is good, but it comes in many flavors. If the
> event was called progresserror for XHR, then that would mean that you
> have to listen for "error" in some places but "progresserror" in
> others, for what is essentially the exact same thing.
>
> That isn't consistent from a author point of view either.
>
> To make matters worse XHR used to use plain Events, but then gained
> the extra feature of reporting progress by adding additional
> properties to its various events. So it would have been very messy if
> we had tried to restrict "error" to just be plain Events.
>
> If we really feel that we must keep consistent with any events that
> DOM Events spec defines, then DOM Events needs to be a lot more
> careful about defining events with generic names. Otherwise other
> specs have to work around DOM Events by arbitrarily using more complex
> names. This doesn't sound like a win for anyone.

Sorry, forgot to tie this back to IndexedDB.

While technically possible to use something other than "error" here, I
think that introduces other inconsistencies for authors. We currently
have a very nice "success"/"error" pairing which is very intuitive.
While we could introduce something like onerror corresponding to
addEventListener("idberror") that is IMHO a much worse inconsistency.
It also makes things very surprising if pages check event.type since
that won't be "error".

Having asynchronous operations always produce "error" events, be they
network requests or database operations, is another nice consistency
we'd loose.

Also, in the firefox implementation we dispatch a "error" event on the
window object if the "error" event isn't cancelled. This is very nice
since it ties in to the error handling mechanism that exists today for
script errors. I.e. it ties in to the window.onerror property which
already exists. This has been discussed on the list and I meant to add
this to the spec when we defined error handling, but it looks like I
forgot. If we weren't using "error" when dispatching to the IDB
objects, then we'd have a bit of inconsistency here too.

Another data point as well is how workers use "error" events. When
code in a worker throws an exception and doesn't catch it, a "error"
event is dispatched against the workers global scope. This is similar
to how window.onerror works. If the worker is a deeply "nested"
worker, i.e. a worker in a worker in a worker, then you get an effect
similar to a bubbling event. The event is dispatched first to the
worker global scope, then to the worker object itself, then to the
workers parent worker and then its parent worker and so on. The effect
is very much like a bubbling event, but the situation is a bit more
complex since all the events are dispatched in different scopes (which
are potentially even in different processes, depending on the
implementation).

So it seems to me that while it's not ideal that different events with
the same name ("error") can either be bubbling or non bubbling
depending which objects the events are dispatched at, it seems like
trying to fix that problem results in much bigger problems and much
bigger inconsistencies.

/ Jonas

Received on Tuesday, 26 April 2011 19:00:22 UTC