User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0 Build ID: 20151026170526 Steps to reproduce: 1. Open an IndexedDB database connection 2. Try deleting the database without first closing the above connection 3. Listen for an "onblocked" event for the deletion Actual results: The event's `oldVersion` is set to 0. Expected results: The event's `oldVersion` should be set to the original db connection's version (e.g., "1"). This is the behavior in Chrome and in the spec at http://www.w3.org/TR/IndexedDB/#dfn-steps-for-deleting-a-database where step 6 states, "If any of the connections in openDatabases are still not closed, and request was provided, fire a blocked event at request. The event MUST use the IDBVersionChangeEvent interface and have the oldVersion property set to db's version..." The editor's draft at http://w3c.github.io/IndexedDB/#dfn-steps-for-deleting-a-database also says to "fire a version change event named blocked at request with db's version"...
Also a problem in 43.0a2 (2015-10-29) Dev. Edition
This is because we read the version in from the database on disk, rather than using the in-memory values if it is currently open.
Probably a regression from PBackground-ification.
DeleteDatabaseOp::SendBlockedNotification() just hardcodes 0. I guess it shouldn't :) Might be able to unify DeleteDatabaseOp::SendBlockedNotification() and OpenDatabaseOp::SendBlockedNotification() now.
Er, wait. That's the current version, and it's correct I think. The problem is actually in http://mxr.mozilla.org/mozilla-central/source/dom/indexedDB/ActorsChild.cpp#1488
After further investigation, this symptom shall already be covered by the test case of |test_deleteDatabase_onblocked.js| provided in bug 823371 comment 3, so I'd like to mark this as the duplication of bug 823371.