If all script references to an IDBRequest have been dropped, it's possible the only thing keeping a request alive is an en-queued event. If that's the case, then if the request is abort()ed the destructor can run in the middle of the abort() method, and asserts. Abbreviated stack trace: ASSERTION FAILED: m_readyState == DONE || m_readyState == EarlyDeath || !scriptExecutionContext() ../../third_party/WebKit/Source/WebCore/Modules/indexeddb/IDBRequest.cpp(83) : virtual WebCore::IDBRequest::~IDBRequest() 1 WebCore::IDBRequest::~IDBRequest() ... 7 WebCore::EventTarget::deref() ... 13 WebCore::Event::~Event() ... 22 WTF::Vector<WTF::RefPtr<WebCore::Event>, 0ul>::clear() 23 WebCore::IDBRequest::abort() 24 WebCore::IDBTransaction::abort(int&) 25 WebCore::IDBTransaction::stop() 26 non-virtual thunk to WebCore::IDBTransaction::stop() 27 WebCore::ScriptExecutionContext::stopActiveDOMObjects() 28 WebCore::Document::detach() 29 WebCore::Document::prepareForDestruction()
Created attachment 159729 [details] Patch
lgtm
Link to Chromium test flake report: http://code.google.com/p/chromium/issues/detail?id=143855
tony@ - r?
Comment on attachment 159729 [details] Patch If there's a way to reliably hit the assert, it would be nice to add a test case for it.
Comment on attachment 159729 [details] Patch Clearing flags on attachment: 159729 Committed r126361: <http://trac.webkit.org/changeset/126361>
All reviewed patches have been landed. Closing bug.