Most of the migration steps in nsBrowserGlue's migrateUI run in a new profile unnecessarily. We should investigate returning early if currentUIVersion == 0.

the problem is that browser.migration.version is an hidden pref we set, it's hard to distinguish a new profile from a profile where this pref has been reset by mistake, plus may be useful to have it settable to zero to debug issues (basically force a re-run of migration). Though, if we could couple that with the age of the profile we could have a better heuristic.

We can add a default value for the pref (-1?) to distinguish from the "manually set to 0" case.

that would solve one of the two cases, the other case is edgy so likely we don't care. Though, we should keep writing migration steps so they can run multiple times, to support the manual case. That so far has been enforced by the fact we were running the steps regardless in new profiles, if we change that we should add a nice comment stating people should detect state of the browser and make the migration step handle running on an already migrated profile.

Note that I think some steps such as step 5 are intended to be run on new profiles. Migration from other browsers (or a Firefox reset) happens before migrateUI and then we want to make some changes as a result. In the case of step 5 I believe we want to show the bookmark toolbar if after import there are more than 3 bookmarks on the toolbar. We should think carefully about the various migrations and consider the migration/reset case.

Removed from Backlog based on team feedback from the point estimation meeting.

FYI: Bug 1029148 plans to add a new migration that I think should also run on new profiles.