Modern IDB: Support IDBDatabase.close() Now that we support versionchange events to open database connections (https://bugs.webkit.org/show_bug.cgi?id=150149), we need to support IDBDatabase.close() to respond to them.
Actually, this does not rely on 150149, and doing it earlier will help with other tests.
Created attachment 263211 [details] Patch v1
Comment on attachment 263211 [details] Patch v1 View in context: https://bugs.webkit.org/attachment.cgi?id=263211&action=review > LayoutTests/storage/indexeddb/modern/opendatabase-versions.html:37 > + request.transaction.db.close(); Try closing it twice in a test.
Comment on attachment 263211 [details] Patch v1 Attachment 263211 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/293001 New failing tests: storage/websql/alter-to-info-table.html
Created attachment 263219 [details] Archive of layout-test-results from ews102 for mac-mavericks The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews102 Port: mac-mavericks Platform: Mac OS X 10.9.5
It seems extremely unlikely that the test failures seem on mac-wk1 could be because of this patch. Will look into them before landing.
(In reply to comment #6) > It seems extremely unlikely that the test failures seem on mac-wk1 could be > because of this patch. > > Will look into them before landing. As is evidenced by: > Unable to pass tests without patch (tree is red?) [results]
It's obvious on the bots that the tests are in terrible shape right now. Builds fine locally, landing soon.
https://trac.webkit.org/changeset/191156
Yikes! A new failure was introduced. Sorry. Trying to rollout now.
Re-opened since this is blocked by bug 150215
Looks like leftovers from an indexeddb test causing a crash (ASSERT) in the first following test - storage/websql/alter-to-info-table.html That said, can't reproduce locally :(
Looks like an error callback from the server coming through to the client *after* the test is over... maybe.
Looks like a release build failure, possibly changing timing enough to cause this latent callback to come in.
(In reply to comment #14) > Looks like a release build failure, possibly changing timing enough to cause > this latent callback to come in. I spotted the obvious bug in the test, and it revealed a very real IDBError crash. Updated patch incoming.
Created attachment 263275 [details] Patch for landing Fixed the issues, I'll just let the CQ deal with landing this.
Comment on attachment 263275 [details] Patch for landing Clearing flags on attachment: 263275 Committed r191182: <http://trac.webkit.org/changeset/191182>