Rough sketch of repro: (1) Start up a worker that opens a DB connection. It should have an onversionchange handler that calls db.close immediately, e.g. self.webkitIndexedDB.open('db').onsuccess = function (e) { self.db = e.target.result; self.db.onversionchange = function () { db.close(); }; }; (2) Once the worker is holding the connection open, from the window open another connection and start a version change transaction: window.webkitIndexedDB.open('db').onsuccess = function (e) { window.db = e.target.result; var request = window.db.setVersion('1'); debugger; request.onsuccess = function () { console.log("called!"); }; }; If a debugger is active (or if the stars align correctly), then at the "debugger" line: * The worker's db.close() call occurs * IDBDatabase::close() calls IDBDatabaseBackendImpl::close() * IDBDatabaseBackendImpl::close() calls IDBDatabaseBackendImpl::processPendingCalls() * The pending SetVersion request is dequeued, and the IDBTransactionBackendImpl created * The transaction starts synchronously * The the transaction executes the version number change step, which calls IDBCallbacks::onSuccess(transaction) * This is implemented by IDBRequest::onSuccess(transaction), which calls enqueueEvent() with a "success" event * The event is dispatched - and there is no "success" handler, so it's a no-op * At the end of the dispatch logic, the IDBTransactionBackendImpl is notified that the task has been processed. * No additional tasks have been scheduled for the IDBTransactionBackendImpl so it commits
This appears to specific to the debugger - the dispatch is occurring as a result of the call from the worker, despite the main JS execution context (terminology?) of the window being halted. dgrogan@ thinks this may be related to https://bugs.webkit.org/show_bug.cgi?id=60790 and aklein@/rafaelw@ indicate they ran into the same issue with Mutation Observers and the debugger. un-assigning as I don't think we need to tackle this immediately.