RESOLVED FIXED 80547
IndexedDB: Creating a transaction from within a transaction callback should fail
https://bugs.webkit.org/show_bug.cgi?id=80547
Summary IndexedDB: Creating a transaction from within a transaction callback should fail
Joshua Bell
Reported 2012-03-07 15:13:02 PST
IndexedDB: Creating a transaction from within a transaction callback should fail
Attachments
Patch (18.31 KB, patch)
2012-03-07 15:16 PST, Joshua Bell
no flags
Patch (17.49 KB, patch)
2012-03-16 11:58 PDT, Joshua Bell
no flags
Patch (3.81 KB, patch)
2012-03-21 16:05 PDT, Joshua Bell
no flags
Patch (3.80 KB, patch)
2012-04-04 16:22 PDT, Joshua Bell
no flags
Patch (30.08 KB, patch)
2012-06-13 12:32 PDT, Alec Flett
no flags
Patch (30.41 KB, patch)
2012-06-13 15:57 PDT, Alec Flett
no flags
Patch (31.11 KB, patch)
2012-06-13 15:59 PDT, Alec Flett
no flags
Joshua Bell
Comment 1 2012-03-07 15:16:29 PST
Joshua Bell
Comment 2 2012-03-07 15:30:27 PST
Given that this is likely to break user code, I'm not sure we should land this before the onupgradeneeded change. That said, we would like to support both setVersion() and onupgradeneeded, so maybe it's okay to land this first, with sufficient warning on the mailing lists. And *that* said, I'm not entirely sure this is correct. As written, the patch only applies to VERSION_CHANGE transactions, i.e. those created in response to setVersion() calls. It precludes calling IDBDatabase.transaction as long as the VERSION_CHANGE transaction is active on the IDBDatabase, regardless of whether it's within the IDBVersionChangeRequest's callback or a dependent IDBRequest's callback. The text in https://www.w3.org/Bugs/Public/show_bug.cgi?id=11401 only applies to the Sync API. I'll follow up on the mailing list.
Joshua Bell
Comment 3 2012-03-07 15:40:38 PST
Ah, the spec now says re: IDBDatabase.transaction() "This method must throw a DOMException of type InvalidStateError if called before the success event for a open call has been dispatched." That applies to the newfangled approach: req = indexedDB.open(name, version); req.onupgradeneeded = function () { var db = req.result; // better not call db.transaction here var putreq = db.createObjectStore(...).put(...); putreq.onsuccess = function () { // better not call db.transaction here }; }; req.onsuccess = function () { var db = req.result; // you can finally call db.transaction now }; The upshot being that you can't call db.transaction while a VERSION_CHANGE transaction is running. This matches the patch's behavior change in spirit, even though the API is radically different. So I'm okay with landing this, now or later.
David Grogan
Comment 4 2012-03-08 14:37:15 PST
LGTM (I looked through this last night but forgot to LGTM it.)
Joshua Bell
Comment 5 2012-03-16 11:23:45 PDT
tony@, r? Opinions on landing this now? I'm still torn between inflicting pain now vs. later.
Joshua Bell
Comment 6 2012-03-16 11:58:59 PDT
Joshua Bell
Comment 7 2012-03-16 12:00:14 PDT
Comment on attachment 132339 [details] Patch FYI, latest patch is just a rebase/merge against the recent test refactoring.
Tony Chang
Comment 8 2012-03-16 12:37:33 PDT
Comment on attachment 132339 [details] Patch The code looks fine. I defer to your judgement about whether to land now or after onupgradeneeded is supported. If there aren't that many clients, it might be OK to land this now.
Joshua Bell
Comment 9 2012-03-21 16:05:32 PDT
Joshua Bell
Comment 10 2012-03-21 16:09:04 PDT
Comment on attachment 133135 [details] Patch Just a rebase on top of r111225 which took care of the test updated.
Joshua Bell
Comment 11 2012-04-04 16:22:13 PDT
David Grogan
Comment 12 2012-04-05 14:00:23 PDT
Comment on attachment 135709 [details] Patch LGTM
Joshua Bell
Comment 13 2012-04-18 11:04:42 PDT
Handing this off to dgrogan@ - let's land it at the same time as onupgradeneeded.
Joshua Bell
Comment 14 2012-06-07 14:27:30 PDT
Alec's going to take ownership of this w/ the error cleanup he's doing, and probably slip this in.
Alec Flett
Comment 15 2012-06-13 12:32:53 PDT
Alec Flett
Comment 16 2012-06-13 13:23:52 PDT
jsbell@ / dgrogan@ - mind taking a look?
Joshua Bell
Comment 17 2012-06-13 13:51:31 PDT
Comment on attachment 147390 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=147390&action=review overall lgtm > Source/WebCore/Modules/indexeddb/IDBTransaction.cpp:86 > + , m_mode(mode) Add ASSERT in constructor that m_mode == m_backend->mode() ? > LayoutTests/storage/indexeddb/mozilla/resources/remove-objectstore.js:-47 > - if (++addedCount == 100) { Remove other uses of addedCount in this file (and -expected.txt) > LayoutTests/storage/indexeddb/resources/database-basics.js:32 > + Nit: remove blank line
Alec Flett
Comment 18 2012-06-13 15:57:46 PDT
Alec Flett
Comment 19 2012-06-13 15:58:34 PDT
Comment on attachment 147435 [details] Patch jsbell's issues addressed. tony@ - r? cq?
Alec Flett
Comment 20 2012-06-13 15:59:46 PDT
Alec Flett
Comment 21 2012-06-13 16:00:08 PDT
Comment on attachment 147436 [details] Patch ooops, forgot to update expectations. new patch, tony@ - r? cq?
WebKit Review Bot
Comment 22 2012-06-14 01:06:22 PDT
Comment on attachment 147436 [details] Patch Clearing flags on attachment: 147436 Committed r120295: <http://trac.webkit.org/changeset/120295>
WebKit Review Bot
Comment 23 2012-06-14 01:06:28 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.