IndexedDB: Don't fire success event callbacks once a transaction has been aborted

RESOLVED FIXED

Status

()

Core
DOM: IndexedDB
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: Ben Turner (not reading bugmail, use the needinfo flag!), Assigned: Ben Turner (not reading bugmail, use the needinfo flag!))

Tracking

unspecified
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Once a transaction has been aborted we should suppress any pending success event callbacks.
This is part of the last set of IndexedDB bugs we've deemed necessary in order to ship 2.0, blocking beta9.
blocking2.0: ? → beta9+
Comment on attachment 497326 [details] [diff] [review]
Patch, v1

We should fire an error event with ABORT_ERR rather than nothing.
Attachment #497326 - Flags: review?(jonas) → review-
Created attachment 497435 [details] [diff] [review]
Patch, v2

Ok, this converts everything to ABORT_ERR events instead.
Attachment #497326 - Attachment is obsolete: true
Attachment #497435 - Flags: review?(jonas)
Comment on attachment 497435 [details] [diff] [review]
Patch, v2

>@@ -370,16 +378,22 @@ AsyncConnectionHelper::OnSuccess(nsIDOME
...
>+#ifdef DEBUG
>+  if (mTransaction && !mTransaction->TransactionIsOpen()) {
>+    NS_ASSERTION(mTransaction->IsAborted(), "How else can this be closed?!");
>+  }
>+#endif

NS_ASSERTION(!mTransaction ||
             mTransaction->TransactionIsOpen() ||
             mTransaction->IsAborted(), "How else can this be closed?!")

Also, shouldn't TransactionIsOpen simply be named to IsOpen?

>+#ifdef DEBUG
>+    if (mTransaction && !mTransaction->TransactionIsOpen()) {
>+      NS_ASSERTION(mTransaction->IsAborted(), "How else can this be closed?!");
>+  }
>+#endif

Same same.

>@@ -931,59 +944,60 @@ CommitHelper::Run()
...
>+    mTransaction->mFiredCompleteOrAbort = true;

#ifdef DEBUG?

r=me with that.
Attachment #497435 - Flags: review?(jonas) → review+
http://hg.mozilla.org/mozilla-central/rev/a1f2e2bb9a7a
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Comment 7

8 years ago
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if  you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
blocking2.0: beta9+ → betaN+
Component: DOM → DOM: IndexedDB
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.