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. 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. 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. A couple of questions: * Do we agree that errors shouldn't be cancelable? * 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? * 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? Thanks, Israel [1] http://www.w3.org/TR/DOM-Level-3-Events/#event-type-error
