For most new users (those who only have one browser installed other than their new fox), migration could be done silently, with no wizard involved whatsoever. It seems Chrome takes this understanding a step further, and always imports from the default browser even if there's few browser installed. However, in Chrome, it's much easier to later tweak your migration needs (see bug 731144). On top of that, it seems there's no need for the multiple-step-wizard, even if migration is not done silently. The simple dialog in Chrome seems to work pretty well. Our wizard has this extra step of dealing with the homepage setting, but it seems that the now-fully-functional about:home and about:newtab pages make it a clear cut: the homepage shouldn't be imported, at least not during first-time migration. We could, instead, import the homepage as a bookmark. ____ Technical note: this blocks bug 718280 due to implementation details. In particular, silent migration means moving more code to MigrationUtils.

I touched on this in bug 1062896 comment 2. Getting rid of the modal wizard should be the main goal, and ideally we could detect whether there is "significant" information to migrate before we ever prompt the user (to avoid annoying people in the "new machine" case).

Some of the tasks/problems to consider: * Source browsers data being locked while the source is opened E.g. are we fine with not importing Chrome/Edge bookmarks, history and passwords if Chrome is running? * Conflict resolution At least it's only unidirectional but this is something we mostly don't worry about since most people aren't re-importing. Example bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1187190 Bookmark example: I have a bookmark for foo.com in Chrome's bookmark bar, import to Firefox's bookmark bar, then move it to a different folder in Firefox. Suppose Chrome isn't propagating the change from Fx, upon next import we shouldn't re-add the bookmark to the Fx bookmark bar (creating a duplicate) but instead re-use the moved one in the new folder. Keep in mind that a URL alone isn't a unique identifier (e.g. you can have the same URL bookmarked multiple times IIRC). Perhaps bookmarks is where this is hardest and we can solve this by always keeping bookmarks in their own browser-specific folder like we do for imports after startup. We can deal with moving/conflicts later. * Migrator UI UI, probably in prefs, to control data types and source browsers + profiles (we support multi-profile on Chrome) Modify current wizard * Scheduling of background import ideally on idle (which I believe we still have a hard time with), try to avoid the user noticing we're using a lot of CPU/IO for no apparent reason * Treating auto-migration like startup-migration Audit all the .startupOnlyMigrator/isStartupMigration code. All of the code looking at isStartupMigration to affect where bookmarks go would probably need to change. We would have to decide if we want the separate bookmark folders or not.