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

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.

-Jacob

[1] http://www.w3.org/2008/webapps/track/issues/176

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@sicking.cc]
> Sent: Monday, April 25, 2011 5:27 PM
> To: Israel Hilerio; Doug Schepers
> Cc: Jacob Rossi; public-webapps@w3.org
> Subject: Re: [IndexedDB] Discrepancies with the Event type of error in section
> 4.12
> 
> On Mon, Apr 25, 2011 at 4:34 PM, Israel Hilerio <israelh@microsoft.com>
> wrote:
> > On Mon, Apr 25, 2011 at 3:13 PM, Jonas Sicking wrote:
> >> On Mon, Apr 25, 2011 at 3:06 PM, Israel Hilerio
> >> <israelh@microsoft.com>
> >> wrote:
> >> > On Mon, Apr 25, 2011 at 11:52 AM, Jonas Sicking wrote:
> >> >> On Mon, Apr 25, 2011 at 9:18 AM, Israel Hilerio
> >> >> <israelh@microsoft.com>
> >> >> wrote:
> >> >> > Step 3 in Section 4.12, "Fire an error event", on the latest
> >> >> > editor draft
> >> >> stipulates that:
> >> >> >
> >> >> > "3. Dispatch an event at request. The event must use the Event
> >> >> > interface
> >> >> and have its type set to "error". The event does bubble and is cancelable.
> >> ..."
> >> >> >
> >> >> > Looking over the DOM L3 event spec, the type "error" Event
> >> >> > doesn't buble
> >> >> and is not cancelable [1].
> >> >> >
> >> >> > Pablo and I are not sure about the benefits of having the error
> >> >> > event be
> >> >> cancelable.  In our experience, canceling and event implies that
> >> >> the reason for this error can be modified or altered.  Leaving
> >> >> this statement would imply that if a developer were to receive a
> >> >> NOT_ALLOWED_ERR she could cancel the error and things would work.
> >> >>
> >> >> Note that 'cancelable' has a specific defined meaning different
> >> >> from the one you describe above. Cancelling a event is done by
> >> >> calling
> >> >> preventDefault() and means that the events "default action" is not
> >> executed.
> >> >> In the case of IndexedDB the default action is to abort the
> >> >> transaction (as defined by step 3).
> >> >>
> >> >> So in other words, if we want to allow users to catch database
> >> >> errors and prevent them from aborting the transaction, which I
> >> >> assume we do, then we need to keep the event cancelable.
> >> >>
> >> >> > The same question applies to bubbling.  What is the intent of
> >> >> > bubbling an
> >> >> error?  For example, if a developer tries to add an object to an
> >> >> objectStore and he fails, where should the event bubble to: the
> >> >> transaction, the database, etc.?  The bubbling hierarchy doesn't
> >> >> seem to be clearly defined.  It would be great to clarify the scenarios
> here.
> >> >>
> >> >> The intent is to allow attaching a event handler to just the
> >> >> transaction object and catch all errors happening in the scope of
> >> >> the transaction. For example is a page uses a transaction to
> >> >> insert 1000 entries into a database, it'd be nice to have a single
> >> >> point of attaching error handling code rather than having to do it
> >> >> on every
> >> individual Request object.
> >> >>
> >> >> Similarly, by allowing the event to bubble up to the database
> >> >> object, event handlers could be attached there that span multiple
> transactions.
> >> >>
> >> >> This is similar to how exceptions work. Exceptions walk up the
> >> >> call chain and allow you to attach error handling code higher up
> >> >> in the call stack which handles all errors in a given execution
> >> >> path. Rather than at each low-level action have to hook up error handling
> code.
> >> >>
> >> >> > Adding bubbling to an event of type "error" would require us to
> >> >> > introduce a
> >> >> new event type, "IDBError".  The reason is that we probably don't
> >> >> want to overload the existing DOM L3 type definition for error.
> >> >> There is a precedence for this in the SVG spec, the SVGError type.
> >> >>
> >> >> I don't see why making the event implement an additional interface
> >> >> would improve the situation. We'd still have to implement the
> >> >> Event interface just like DOM-Events, since all events have to implement
> Event.
> >> >>
> >> >> But I also don't think it's a problem that we fire an event that
> >> >> is similar to the one DOM-Events define, even though it uses the
> >> >> same name. The event isn't fired on the same objects and so no
> >> >> collisions should
> >> occur.
> >> >>
> >> >> I do agree it's somewhat unfortunate that some "error" events
> >> >> bubble, but others don't. But I think it'd be even worse to use a
> >> >> different event name, or to make the event not bubble.
> >> >>
> >> >> > A couple of questions:
> >> >> > * Do we agree that errors shouldn't be cancelable?
> >> >>
> >> >> I think we should leave it cancelable as to allow pages to do
> >> >> error handling and not abort the transaction.
> >> >>
> >> >> > * How do we feel about bubbling?  If we want to keep it, what
> >> >> > are the main
> >> >> scenarios and what would the event hierarchy look like?
> >> >>
> >> >> The propagation part is defined in step 3. During the bubbling
> >> >> phase handlers at the IDBRequest are run first, then the ones at
> >> >> the IDBTransaction and then finally at the IDBDatabase.
> >> >>
> >> >> > * Assuming bubbling, how do you feel about adding a new event
> >> >> > type called
> >> >> IDBError to capture the non-cancelable and bubbling behavior of
> >> >> this
> >> event?
> >> >>
> >> >> I don't see what problem that solves?
> >> >>
> >> >> / Jonas
> >> >
> >> > The canceling and bubbling the error event scenarios make sense to
> >> me.  Thanks for clarifying!
> >> >
> >> > You are correct, we don't want to implement another interface.
> >> > What I was
> >> proposing is to define a new event type for indexedDB errors not a
> >> new interface.  We would still use the same onerror attribute but the
> >> event type would be called "IDBError", not "error".  This would allow
> >> us to define our own bubbling and canceling behavior on the existing Event
> interface.
> >> >
> >> > Since, the DOM L3 event "error" type does neither (bubbling and
> >> > canceling),
> >> that seems to be a good reason for us defining a new type (not
> >> interface) called IDBError.
> >>
> >> While I don't think it's great that the "error" event which is fried
> >> at DOM Nodes doesn't bubble, but the ones fired at IDB objects does
> >> bubble, I think introducing a new name is an even bigger surprise and
> >> inconsistency for authors.
> >>
> >> Note for example that it would mean that you no longer do
> >> request.onerror = myerrorhandler, but rather request.onIDBError =
> myerrorhandler.
> >>
> >> > Do you see any scenarios where we should support the capture phase
> >> > for
> >> the error event?
> >>
> >> The capture phase is supported on *all* events. This is defined by
> >> the DOM Events spec.
> >>
> >> / Jonas
> >
> > I don't believe there is a requirement for naming your event attributes as
> "on<EVENT type>" (e.g. onIDBError).  However, we do see this as a common
> convention.
> > The SVG Team solved this issue by introducing a new Event type called
> "SVGError" and continued to use the same event attribute name "onerror"
> [2].  The code looks like:
> > * onerror = foo;
> > * addEventListener("SVGError", foo, false);
> >
> > Notice they are not following the convention:
> > * onSVGerror = foo;
> 
> This seems like an even worse solution IMHO. I really think this would be
> solving a relatively small inconsistency by introducing an very bad and even
> bigger inconsistency.
> 
> The SVG spec made many mistakes in its initial design and in all too many ways
> integrates poorly with HTML and the way it uses for example the DOM and CSS.
> So I don't think that just because it does something that it's a good pattern that
> we should follow.
> 
> > In talking to our team members (Jacob Rossi) who are working on DOM L3
> events, they feel it wouldn't be correct to take a dependency on DOM L3 events
> and yet define the "error" event type in IndexedDB to bubble and be
> cancelable.  In addition, this would force us to special case the handling of
> error events for IndexedDB.
> 
> The "error" event is already relatively overloaded. Even in the DOM Events
> specification it can use two different interfaces depending on where the error
> originates from. And yet it fails to mention the fact that in many cases it should
> be a third type of interface, ProgressEvent, for for example XMLHttpRequest.
> 
> Would you feel ok with simply making the DOM L3 spec say that the
> bubble/cancelability of the event depends on the context? I.e. that it doesn't
> bubble or is cancelable for network requests, but can in other contexts.
> 
> Doug, would you be ok with such a change?
> 
> / Jonas

Received on Tuesday, 26 April 2011 01:12:40 UTC