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

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;

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.

Regarding event capturing, I just wanted to validate that this was going to be the case since our objects are not part of the DOM tree.

Let me know your thoughts.  Thanks!

[2] http://www.w3.org/TR/SVG/interact.html

Received on Monday, 25 April 2011 23:34:36 UTC