http://w3c-test.org/html/infrastructure/common-dom-interfaces/collections/domstringlist.html It seems like the indexeddb.open() call is returning an AbortError in such a fashion that it's caught by the global error handler in the same way as an uncaught exception, even though an onerror handler is specified on a subsequent line. Chrome and Edge don't do this. What's happening? This seems related to bug 1120178 comment #5.

Jan, please take a look.

Looks like the issue is that idbfactory errors are always reported on the window if the thing they were fired on does not preventDefault. See IndexedDatabaseManager::CommonPostHandleEvent and sgo->HandleScriptError() call in there. We also fire error events on the global in workers, looks like. I don't see anything in the idb spec saying we should do that, and it's not clear to me why we're doing it.

Andrea, do you know what the error reporting story here is and why we do it?

> We also fire error events on the global in workers, looks like. > > I don't see anything in the idb spec saying we should do that, and it's not > clear to me why we're doing it. This seems old code. Wondering if the spec was saying that before indexedDB-2. I take this bug.

Comment on attachment 8912144 [details] [diff] [review] idb.patch :bevis, it looks like your work on bug 1274938 and the spec discussion on https://github.com/w3c/IndexedDB/issues/49 that you're involved with is still relevant, so I'm transferring this review to you. One thing worth noting is that even if we want to remove the window.onerror firing at content, this also removes the ScriptErrorHelper::Dump() that I think in various cases has helped us diagnose weird IDB problems. We should make sure we've got IDB_WARNING paths for everything we care about if removing it.

Comment on attachment 8912144 [details] [diff] [review] idb.patch Review of attachment 8912144 [details] [diff] [review]: ----------------------------------------------------------------- The implementation was done in bug 607729 and the only information I have is on bug 1274938 comment 6 before :sicking leaved. :\ This feature seems wanted for a long time by both Chrome/Firefox according to https://github.com/w3c/IndexedDB/issues/49#issue-110290805 but we didn't have it specified in v2(the milestone now is set to v3). Instead of removing the implementation entirely, I'd prefer to have a preference to enable firing (window|self).onerror in http://searchfox.org/mozilla-central/rev/3dbb47302e114219c53e99ebaf50c5cb727358ab/dom/indexedDB/IndexedDatabaseManager.cpp#549-594 and the default value of this preference is false for now. Then, we could still have error printed in the error console for developers to debug: http://searchfox.org/mozilla-central/rev/3dbb47302e114219c53e99ebaf50c5cb727358ab/dom/indexedDB/IndexedDatabaseManager.cpp#596-603 Does this make sense to you?

Here is the naming rule of idb preference for your reference: http://searchfox.org/mozilla-central/rev/3dbb47302e114219c53e99ebaf50c5cb727358ab/dom/indexedDB/IndexedDatabaseManager.cpp#142-171

Do you mind to file a spec issue?

Comment on attachment 8912529 [details] [diff] [review] idb2.patch Review of attachment 8912529 [details] [diff] [review]: ----------------------------------------------------------------- Thanks! BTW, the spec issue is already available in https://github.com/w3c/IndexedDB/issues/49

Ok, thanks for fixing this.

Pushed by amarchesini@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/e7403204c8fa IDB should not propagate the error events to self.onerror, r=bevis