Bugzilla

(In reply to Jens Stutte [:jstutte] from comment #5)
> OK, I was looking again at the old pernosco trace, and it seems we never pass through the normal shutdown sequence here. `QuotaManager::Shutdown` is never called, as we exit the process through a "xul-window-destroyed" notification which ends up calling `nsAppStartup::Quit` which does not [sweep through all our shutdown phases](https://searchfox.org/mozilla-central/rev/b0e929cfaf3994cad2dd02afdac138083ee3fc84/toolkit/components/startup/nsAppStartup.cpp#481-501), apparently.

Scratch that, it is just the order of things. The rest of the shutdown phases would have been kicked off on `~ScopedXPCOMStartup` but we fail earlier inside a content process.
 
> This could explain why we end up in `XPCOMShutdown` with IDB transactions that have not been canceled.

The general scenario seems to be that we have two open requests inside an IDB Transaction in a content process when the main app is starting shutdown and asks thus all content processes to shut down (which happens before `QuotaManager:.Shutdown` runs in the parent). So I'll probably return to the hypothesis of comment 2 and comment 3 that we have some flaw in aborting with the `aWhy == NormalShutdown` case when there is more than one request active in the transaction.

(In reply to Jens Stutte [:jstutte] from comment #5)
> OK, I was looking again at the old pernosco trace, and it seems we never pass through the normal shutdown sequence here. `QuotaManager::Shutdown` is never called, as we exit the process through a "xul-window-destroyed" notification which ends up calling `nsAppStartup::Quit` which does not [sweep through all our shutdown phases](https://searchfox.org/mozilla-central/rev/b0e929cfaf3994cad2dd02afdac138083ee3fc84/toolkit/components/startup/nsAppStartup.cpp#481-501), apparently.

Scratch that, it is just the order of things. The rest of the shutdown phases would have been kicked off on `~ScopedXPCOMStartup` but we fail earlier inside a content process.
 
> This could explain why we end up in `XPCOMShutdown` with IDB transactions that have not been canceled.

The general scenario seems to be that we have two open requests inside an IDB Transaction in a content process when the main app is starting shutdown and asks thus all content processes to shut down (which happens before `QuotaManager::Shutdown` runs in the parent). So I'll probably return to the hypothesis of comment 2 and comment 3 that we have some flaw in aborting with the `aWhy == NormalShutdown` case when there is more than one request active in the transaction.

(In reply to Jens Stutte [:jstutte] from comment #5)
> OK, I was looking again at the old pernosco trace, and it seems we never pass through the normal shutdown sequence here. `QuotaManager::Shutdown` is never called, as we exit the process through a "xul-window-destroyed" notification which ends up calling `nsAppStartup::Quit` which does not [sweep through all our shutdown phases](https://searchfox.org/mozilla-central/rev/b0e929cfaf3994cad2dd02afdac138083ee3fc84/toolkit/components/startup/nsAppStartup.cpp#481-501), apparently.

Scratch that, it is just the order of things. The rest of the shutdown phases would have been kicked off on `~ScopedXPCOMStartup` but we fail earlier inside a content process (thanks to Nika for pointing me there).
 
> This could explain why we end up in `XPCOMShutdown` with IDB transactions that have not been canceled.

The general scenario seems to be that we have two open requests inside an IDB Transaction in a content process when the main app is starting shutdown and asks thus all content processes to shut down (which happens before `QuotaManager::Shutdown` runs in the parent). So I'll probably return to the hypothesis of comment 2 and comment 3 that we have some flaw in aborting with the `aWhy == NormalShutdown` case when there is more than one request active in the transaction.