Bugzilla

(In reply to Nick Alexander :nalexander [he/him] from comment #16)
> In regular browsing, this is probably something like [`final-ui-startup`](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/toolkit/xre/nsAppRunner.cpp#5669), but that event should be fired before we invoke [the background task code](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/toolkit/xre/nsAppRunner.cpp#5774).
> 
> I'm not aware of any other event that might play that role, leaving us with the status quo: components should (but fail) to accommodate shutdown even while they start up :(

Is [`_onWindowsRestored`](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/browser/components/BrowserGlue.sys.mjs#2268) ever called in background tasks? I see `browser-startup-idle-tasks-finished` caused by this probably sufficiently late. But startup idle tasks contain things that we [really do not want to run in case of an early shutdown](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/browser/components/BrowserGlue.sys.mjs#2896), so it would be probably the wrong event, anyways. Actually I'd hope we do not try to run them at all in background task mode, but did not try to follow through the code path here.

A hacky way of mitigating this a bit could be to do a delayed dispatch of [`Services.startup.quit(Ci.nsIAppStartup.eForceQuit, exitCode);`](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#231) instead of invoking it directly. We could even measure the time passed from starting the background task to finishing it and calculate a delay based on that and a pref for a minimum background task lifetime or such. That pref could have different values for Nightly and Release such that we capture more hangs on nightly and can slowly work towards "components should (but fail) to accommodate shutdown even while they start up :(" ?

Connected with this at the opposite side of the lifecycle there might be an additional timing question at least for background tasks spawned during browser shutdown: Browser shutdown can be very expensive in terms of CPU cycles/threads and it seems not unlikely that the background task will just make this worse and won't make progress on its task immediately. We might want to think of an initial delay here, maybe as command line parameter. If we evaluate this parameter early enough we could even avoid that the startup ceremony causes additional load here, too.

(In reply to Nick Alexander :nalexander [he/him] from comment #16)
> In regular browsing, this is probably something like [`final-ui-startup`](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/toolkit/xre/nsAppRunner.cpp#5669), but that event should be fired before we invoke [the background task code](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/toolkit/xre/nsAppRunner.cpp#5774).
> 
> I'm not aware of any other event that might play that role, leaving us with the status quo: components should (but fail) to accommodate shutdown even while they start up :(

Is [`_onWindowsRestored`](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/browser/components/BrowserGlue.sys.mjs#2268) ever called in background tasks? I see `browser-startup-idle-tasks-finished` caused by this probably sufficiently late. But startup idle tasks contain things that we [really do not want to run in case of an early shutdown](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/browser/components/BrowserGlue.sys.mjs#2896), so it would be probably the wrong event, anyways. Actually I'd hope we do not try to run them at all in background task mode, but did not try to follow through the code path here.

A hacky way of mitigating this a bit could be to do a delayed dispatch of [`Services.startup.quit(Ci.nsIAppStartup.eForceQuit, exitCode);`](https://searchfox.org/mozilla-central/rev/17aeb39742eba71e0936ae44a51a54197100166d/toolkit/components/backgroundtasks/BackgroundTasksManager.sys.mjs#231) instead of invoking it directly. We could even measure the time passed from starting the background task to finishing it and calculate a delay based on that and a pref for a minimum background task lifetime or such. That pref could have different values for Nightly and Release such that we capture more hangs on nightly and can slowly work towards "components should (but fail) to accommodate shutdown even while they start up :(" ?

Connected with this at the opposite side of the lifecycle there might be an additional timing question at least for background tasks spawned during browser shutdown: Browser shutdown can be very expensive in terms of CPU cycles/threads and it seems not unlikely that the background task will just make this worse and won't make progress on its task immediately. We might want to think of an initial delay here, maybe as command line parameter. If we evaluate this parameter early enough we could even avoid that the startup ceremony causes additional load here, too. (I did not check if we have already something like this)