Profile Manager API in Firefox needs to invoke automigrator when there are zero profiles present on the system to read data from default browser after the app is installed for the first time. This requires adding an interface (nsIProfileMigrator) which Firefox (and potentially any other app that has other apps to migrate data from) implements which determines the default browser and migrates data from it.

take target

Comment on attachment 142086 [details] [diff] [review] patch to add new nsIProfileMigrator interface and add caller in profile startup >Index: profile/public/nsIProfileMigrator.idl >=================================================================== >+#include "nsISupports.idl" >+ >+[scriptable, uuid(5d9c7f6a-4af4-4a3d-be48-da1e70600b9c)] >+interface nsIProfileMigrator : nsISupports >+{ >+ /** >+ * Copy user profile information to the current active profile. >+ */ >+ void migrate(); Seems it should add the migrated info to the registry and copy the files when the profile is not active. If copied when active, what happens to open files in that profile that are in use? I'd like to keep migrating and setCurrentProfile distict. Maybe that's what it does and I'm misinterpreting the meaning of "active?" Looks good. Clarify that and I'll finish reviewing.

The problem is that not every migration excercise can be done with the profile is inactive. Some can (e.g. Seamonkey and Dogbert migration since they're just file-copy operations), but some can't, such as pretty much everything else - IE, Opera, Safari, etc. since they rely on the relevant data services being running with an active profile so they can use the relevant methods to add items. The Profile Migrator implementation makes this determination when it figures out your default browser: http://lxr.mozilla.org/mozilla/source/browser/components/migration/src/nsProfileMigrator.cpp#61 If the browser is Seamonkey or Dogbert it knows it can begin right away, otherwise it adds an observer for a notification sent before the browser window appears when there's an active profile. Does that make sense?

Comment on attachment 142086 [details] [diff] [review] patch to add new nsIProfileMigrator interface and add caller in profile startup Yeah, that makes sense. r=ccarlen with some more documentation in nsIProfileMigrator.idl.

I actually don't need to place this in profile after all. It works better in appshell, before the profile manager has the chance to do anything else that might interfere with what we're doing. The positioning/content of this code may move one more time when we do the new profile management system in Firefox.

I'm checking in the piece of the first patch that exposes "createDefaultProfile" but nothing else.

Comment on attachment 142822 [details] [diff] [review] patch to appshell Umm, OK. This thing someone stuck into my hand feels mighty and ropey. I'm assuming it goes with the rest of the elephant. No gold star for you because of all the skanky only-in-phoenix ifdefs, but r=danm anyway. Knock yerself out.

Ben, I like the new approach much better. It's along the lines of what I mentioned in email about moving app-specific startup activies out of profile mgr and into the app :-)

Cool. I'm hoping the discussion with Benjamin on profile manager stuff and Firefox will continue... if that continues to develop then this code may even lift out of appshell and go into the XRE apprunner, or register as a startup service.

OK - this is fixed for now. Thanks dan/conrad!

.