Bugzilla

As a retrospective to Bug 1740987, I must admit our startup path is a bit weak, the browser is in a non-working state for a lot of features, because startup was interrupted.

This time it was _beforeUIStartup throwing due to _migrateUI(), but other parts of the BG startup suffer of similar issues. For example _onWindowsRestored(), as well as _onFirstWindowLoaded() are all methods that execute a bunch of unrelated code from different modules, and failing one will skip all the next ones.

For shutdown and idle tasks we solved the problem defining each single step as a task, and catching exceptions so that the process can continue even if one step fails. 
Even if we decide to catch single cases, we should still cause evident test failures if something in the startup path throws, it should be possible to emit a test failure text that can be catched by the test harness.

Fwiw, this wouldn't have helped migrateUI because most of those migrations run only if there's something to migrate, and tests unlikely have stuff to migrate. Moreover it's unclear if failing ui migration will leave the browser in an unusable state or not, because that depends on the specific migration we are running.

As a retrospective to Bug 1740987, I must admit our startup path is a bit weak, the browser is in a non-working state for a lot of features, because startup was interrupted.

This time it was _beforeUIStartup throwing due to _migrateUI(), but other parts of the BG startup suffer of similar issues. For example _onWindowsRestored(), as well as _onFirstWindowLoaded() are all methods that execute a bunch of unrelated code from different modules, and failing one will skip all the next ones.

For shutdown and idle tasks we solved the problem defining each single step as a task, and catching exceptions so that the process can continue even if one step fails. 
Even if we decide to catch single cases, we should still cause evident test failures if something in the startup path throws, it should be possible to emit a test failure text that can be catched by the test harness.

Fwiw, this wouldn't have helped detecting the migrateUI case because most of those migrations run only if there's something to migrate, and tests unlikely have stuff to migrate. Moreover it's unclear if failing ui migration will leave the browser in an unusable state or not, because that depends on the specific migration we are running.