Added a note for that step: Even if the event is cancelled (by a call to preventDefault), follow the steps for aborting a transaction.
> -----Original Message----- > From: Jonas Sicking [mailto:[email protected]] > Sent: Monday, August 22, 2011 5:27 PM > To: Eliot Graff > Cc: Israel Hilerio; [email protected]; Tom Bolds; Adam Herchenroether; > Victor Ngo; [email protected] > Subject: Re: FW: [indexeddb] transaction commit failure > > We should also explicitly mention that canceling the event (by calling > preventDefault) does *not* prevent the transaction from being aborted. > > / Jonas > > On Mon, Aug 22, 2011 at 2:27 PM, Eliot Graff <[email protected]> > wrote: > > I added a step 3 to 4.3 Steps for committing a transaction: > > > > 3. If an error occurs while committing the transaction, fire an error event > with type set to UNKNOWN_ERROR, and then follow the steps for aborting a > transaction. > > > > Thanks, > > > > Eliot > > > >> -----Original Message----- > >> From: [email protected] [mailto:public-webapps- > >> [email protected]] On Behalf Of Jonas Sicking > >> Sent: Wednesday, August 17, 2011 4:56 PM > >> To: Israel Hilerio > >> Cc: [email protected]; Tom Bolds; Adam Herchenroether; Victor > >> Ngo; [email protected] > >> Subject: Re: FW: [indexeddb] transaction commit failure > >> > >> On Wed, Aug 17, 2011 at 3:08 PM, Israel Hilerio > >> <[email protected]> > >> wrote: > >> > On Tuesday, August 16, 2011 8:08 AM, Jonas Sicking wrote: > >> >> On Monday, August 15, 2011, Shawn Wilsher <[email protected]> > >> wrote: > >> >> > On 8/15/2011 3:31 PM, Israel Hilerio wrote: > >> >> >> > >> >> >> When the db is doing a commit after processing all records on > >> >> >> the transaction, if for some reason it fails, should we produce > >> >> >> an error event first and let the bubbling produce a transaction > >> >> >> abort event or should we only produce a transaction abort > >> >> >> event. It seems that doing the first approach would be more > complete. > >> >> > > >> >> > I agree; the first approach seems better and I can't think of > >> >> > any reason > >> why it would be difficult to implement. > >> >> > > >> >> > The catch is that calling `preventDefault` will not prevent the > >> >> > abort, > >> which is (I think) different from how we handle other errors, right? > >> >> > >> >> Yeah, I'm tempted to say that that is enough of a reason for > >> >> simply firing > >> abort directly, but I could be convinced otherwise. > >> >> > >> >> / Jonas > >> > > >> > We would like to follow the first approach because it allows us to > >> > notify the > >> developer that there was an error on the transaction and that is the > >> reason the transaction was aborted. > >> > >> Ok, that works for me. > >> > >> / Jonas > >> > > > >
