191555 - Ability to prevent profile migration (via a pref)

Status: RESOLVED FIXED

(Core Graveyard :: Profile: Migration, enhancement)

Description

[Ben Bucksch (:BenB)]

Mozilla is claimed to be an app toolbox, as used as such, as base for
non-browser applications. These applications don't want to interfere with
browser profiles and don't want to have 4.x or Mozilla profile to be migrated
either. There is no point in having your bookmarks and mail migrated, if you're
creating a music player using XUL.
It might also be useful for admins deciding that they don't want Mozillas being
rolled out to migrate from any 4.x profiles which might linger around, so these
admins can change the default pref as well.

Compare bug 186073.

Add a pref to prevent automigration. At the first start, Mozilla should just
create a default profile, as if there were no 4.x profiles.

Comment 1

[Ben Bucksch (:BenB)]

Attachment: Proposed Fix, Version 1, against 1.0.2

Implements pref "profile.allow_automigration", default true. Patch is against
1.0.2, but I can migrate it to the trunk, if it's generally OK. Compiles and
works on Linux, other platforms untested so far.

Comment 2

[Conrad Carlen (not reading bugmail)]

The intended way of doing this, and what embedding apps do, is for the app to
1. Define its own location for profiles by passing an
nsIDirectoryServiceProvider to NS_InitEmbedding.
2. Use only the nsIProfile iface. Using this interface, no migration can happen.

The problem you're encountering happens only with apps which use nsAppRunner,
and nsIAppShellService.

The profile mgr needs to have a lot of code which makes app-level decisions,
like whether to migrate, stripped out of it and moved into app-level code
(nsAppShellService in the case of mozilla). But, since you're talking about the
1.02 branch, I think this pref will do.

Comment 3

[Conrad Carlen (not reading bugmail)]

Comment on attachment 113302 [details] [diff] [review]
Proposed Fix, Version 1, against 1.0.2

r=ccarlen - for 1.0.2 only

Comment 4

[Ben Bucksch (:BenB)]

Conrad, thanks for the fast review.

> The intended way of doing this, and what embedding apps do, [...]

I am not talking about embedding (using Gecko in another application), but
writing applications using XUL and delivering Mozilla as execution environment
together with the app. (Comparable to Java / Java VM.) Most such apps I saw
don't want to touch much C++, much less implement interfaces or an replacement
for apprunner. Often, they chose Mozilla specifically not to have to deal much
with C++ (compiling on each iteration on 3 platforms etc.).

Also, it is arguable, if 4.x migration still makes sense even for Mozilla
browsers, given that Mozilla / Netscape 7 should have a larger market share than
4.x by now, and e.g. Beonex Communicator uses a different base profile dir (so
won't use Netscape 7 profiles) . It would be ridiculous to migrate old 4.x
profiles and leave Netscape 7 profiles alone when the user installs Beonex
Communicator.

I thus think that the patch is useful for the trunk as well. Do you agree?

Comment 5

[Conrad Carlen (not reading bugmail)]

For now, yes. The problem with the profile mgr is that it's too NS
browser-centric. It shouldn't decide migration policy - that's an app-level
thing. Nor should it parse a command line - the app should do that and make
profile mgr API calls.

But, since I don't know when I'll be able to rewrite it and make it that way,
adding code in the profile mgr to read the pref will have to do until then.

Comment 6

[Ben Bucksch (:BenB)]

Totally irrelevant now, given that other apps can use their own profile dirs.

Marking FIXED, because there was a patch (hopefully commited).