286557 - Need an easy way to skip/disable/turn off the Import Wizard (profile migration) on first startup (when no profile exists)

Status: RESOLVED FIXED

(Firefox :: Migration, enhancement, P4)

Description

[Guido Günther]

User-Agent:       Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.7.5) Gecko/20050105 Galeon/1.3.19 (Debian package 1.3.19-4)
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; de-DE; rv:1.7.5) Gecko/20050110 Firefox/1.0 (Debian package)

It would be nice if there would be a config file option to skip the import
wizard on first startups, even if it finds a mozilla installation it could
upgrade from.

We're trying to install mozilla and firefox in paralled in a rather large
environment, therefore we have both browsers preconfigured so there's no need
for Firefoxe's "Import Wizard" to be run. Unfortunately I couldn't find a config
option to avoid this (although I can't believe there isn't any already).


Reproducible: Always

Steps to Reproduce:
1. Run Mozilla (1.7.5)
2. Start Firefox


Actual Results:  
Import Wizard starts up

Expected Results:  
Import Wizard shouldn't run since there's a general config.config.filename set
already (or better there should be an additional option to skip the config wizard)

Comment 1

[Elmar Ludwig]

*** Bug 286711 has been marked as a duplicate of this bug. ***

Comment 2

[Guido Günther]

Sorry this got filed twice, no idea though how this happend. The config option
below should read:
general.config.filename
not
config.config.filename

Comment 3

[Mike Ducharme]

I really need a way around this myself, as I imagine many wanting to roll-out
firefox to corporate networks. If you want to spur corporate adoption to firefox
you should add an option to do this.

Comment 4

[Mike Ducharme]

To go along with this, it would be beneficial to many IT managers to be able to
force a certain import setting when Firefox creates a new profile. There should
be an option to force import nothing (new profile from scratch), force import
IE, force import (insert other browser here), etc. That way companies moving
from IE or whatnot would be able to more easily so that their users would
automatically get a profile migrated from IE rather than having to choose the
option in the import wizard.

Comment 5

[Benjamin Smedberg]

Putting on the radar, but no guarantees. Patches are very welcome!

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Forced migration was implemented in Thunderbird, in bug 291259.

Comment 7

[Dan Fischbach]

I read in /Firefox Hacks/ you could somehow setup a file to answer installation
questions.  I'm assuming this would only work on an MSI installer?  Maybe this
could be brought up during the installation?  If it would be, it should be
placed right after the install screen, but before the finished (last) screen.  I
am thinking the screen should look something like this (or you could just use
something like the current import screen):

+-----------------------------------------------------+
|            MOZILLA FIREFOX 1.1 INSTALLER            |
|-----------------------------------------------------|
| Import Options                                      |
|   Please select which browser, if any, you would    |
|   like to import your settings from.                |
|-----------------------------------------------------|
| (*) Don't import anything                           |
|                                                     |
| ( ) Import settings from Internet Explorer          |
|                                                     |
| ( ) Import settings from <insert another browser    |
|     name here>                                      |
|                                                     |
| Note: Even though your settings are imported into   |
| Firefox, they are not permanently moved.  All of    |
| the settings in the browser you are importing from  |
| are maintained.                                     |
|                                                     |
|                                     +----------+    |
|                                     |   Next   |    |
|                                     +----------+    |
+-----------------------------------------------------+

Comment 8

[Jaime Mitchell (use [e-mail] for email)]

*** Bug 264464 has been marked as a duplicate of this bug. ***

Comment 9

[Benjamin Smedberg]

I'm not going to get to this for 1.1

Comment 10

[Mike Kaply [:mkaply]]

Doing this as part of the install isn't adequate - many companies do unattended
install.

This should probably be a preference and it can be set as part of the CCK or
something.

Comment 11

[Mike Kaply [:mkaply]]

It would be straightforward to add a pref to simple ignore this chunk of code:

http://lxr.mozilla.org/seamonkey/source/toolkit/xre/nsAppRunner.cpp#2185

Would that be too simplisitic?

Comment 12

[Benjamin Smedberg]

mkaply, that hunk of code runs before we load extensions and prefs (we must not
load prefs before running most of the profile migrators), so something that uses
the pref service is really out of the question. Checking for the existence of a
special file in the installdir is what I was thinking.

Comment 13

[Benjamin Smedberg]

*** Bug 305617 has been marked as a duplicate of this bug. ***

Comment 14

[Mike Ducharme]

What I was thinking is an auto-answer script for the profile wizard in the main
program dir. Then it could be used to turn off the import wizard or force import
from IE or whatever an organization needed to do.

Comment 15

[timeless]

for my reference (as a potential embedder), can i choose not to build the 
migrators?

Comment 16

[Benjamin Smedberg]

The migrators are app-specific, so they should not affect embedding unless you
are trying to embed firefox instead of just the platform.

Comment 17

[timeless]

i'm likely to just embed the app instead of the platform given that i have yet
to be able to wait for any release ...

Comment 18

[Darin Fisher]

I think you can define XRE_IMPORT_PROFILES=1 in your environment to disable
profile migration.

Comment 19

[dan050782]

It would also be a good idea to include the "import from file" option when the import wizard first appears.  Instead of having to cancel it and run it a second time to get this option.

Comment 20

[Mike Kaply [:mkaply]]

If I can get more brainstorming on this, I'll implement it. I would love to make it simple enough that 1.8.0.2 would take it.

So the idea is somesort of file like:

import.ini or such

Syntax would be something probably like this:

[Microsoft Internet Explorer]
Import=Yes/No
Internet Options=Yes/No
Cookies=Yes/No
Browsing History=Yes/No
Saved Form History=Yes/No
Saved Passwords=Yes/No
Favorites=Yes/No

[Netscape 6, 7 or Mozilla 1.x]
Import=Yes/No
Bookmarks=Yes/No

[Netscape 4.x]
Import=Yes/No
Cookies=Yes/No
Bookmarks=Yes/No


bsmedberg: is there INI parsing code that can be used at this point?

Do we import from Opera as well?

Comment 21

[Mike Kaply [:mkaply]]

The migration code is contained in the JS migration.js.

It doesn't happen in C code. 

Target for a first release would probably be to just make migration not happen, not customize it.

Comment 22

[Benjamin Smedberg]

nsINIParser handles INI parsing, or nsIINIParser for scriptable usage.

I recommend the simple route is simply disabling profile migration in the application flags at http://lxr.mozilla.org/mozilla/source/browser/app/nsBrowserApp.cpp#55

The other option is to disable the migration at http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsAppRunner.cpp#2184 or http://lxr.mozilla.org/mozilla/source/toolkit/xre/nsAppRunner.cpp#1581

The INI flag should then be (IMO):

[XRE]
EnableProfileMigrator=false

Which matches the application.ini parsing for xulrunner (see http://lxr.mozilla.org/mozilla/source/xulrunner/app/nsXULRunnerApp.cpp#225).

Comment 23

[Mike Kaply [:mkaply]]

Attachment isn't working for some reason. Here's an initial proof of concept - need a better INI name.

Index: nsAppRunner.cpp
===================================================================
RCS file: /cvsroot/mozilla/toolkit/xre/nsAppRunner.cpp,v
retrieving revision 1.113.2.4
diff -u -r1.113.2.4 nsAppRunner.cpp
--- nsAppRunner.cpp	17 Oct 2005 19:16:51 -0000	1.113.2.4
+++ nsAppRunner.cpp	12 Jan 2006 23:05:01 -0000
@@ -2168,6 +2168,26 @@
       // So we can open and close windows during startup
       appStartup->EnterLastWindowClosingSurvivalArea();
 
+      nsCOMPtr<nsIFile> file;
+      profD->Clone(getter_AddRefs(file));
+      file->AppendNative(NS_LITERAL_CSTRING("profilemigrate.ini"));
+      PRBool exists = PR_FALSE;
+      file->Exists(&exists);
+      if (exists) {
+        nsINIParser parser;
+        nsCOMPtr<nsILocalFile> localFile(do_QueryInterface(file));
+        nsresult rv = parser.Init(localFile);
+        if (NS_SUCCEEDED(rv)) {
+          nsCAutoString buf;
+          rv = parser.GetString("XRE", "EnableProfileMigrator", buf);
+          if (NS_SUCCEEDED(rv)) {
+            if (buf[0] == '0' || buf[0] == 'f' || buf[0] == 'F') {
+              gDoMigration = PR_FALSE;
+            }
+          }
+        }
+      }
+
       // Profile Migration
       if (gAppData->flags & NS_XRE_ENABLE_PROFILE_MIGRATOR && gDoMigration) {
         gDoMigration = PR_FALSE;

Comment 24

[Mike Kaply [:mkaply]]

Attachment: Complete fix

OK, this is a complete fix.

Main change is that I put the whole thing in gDoMigration so it only gets executed if we were going to migrate anyway.

Also, I settled on a name - profilemigrator.ini

Comment 25

[Benjamin Smedberg]

Comment on attachment 208383 [details] [diff] [review]
Complete fix

Please change "profilemigrator.ini" to "override.ini"... I'd like at some point to stick other information in this file (e.g. for bug 283779).

Comment 26

[Mike Kaply [:mkaply]]

Fix checked in.

This bug as written is fixed.

If we want to actually customize the import, I believe that is a separate bug.

Comment 27

[Mike Kaply [:mkaply]]

Comment on attachment 208383 [details] [diff] [review]
Complete fix

I'd like to get this on the 1.8.0.2 radar.

This is a very small change that will give us a necessary enterprise feature.

It's little/no risk.

Comment 28

[Daniel Veditz [:dveditz]]

Not blocking a security release, might approve the patch

Comment 29

[Daniel Veditz [:dveditz]]

Comment on attachment 208383 [details] [diff] [review]
Complete fix

approved for 1.8.0 branch, a=dveditz

Comment 30

[Dave Liebreich [:davel]]

for verification - in what directory should the profilemigrator.ini file be added?

Comment 31

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #30)
> for verification - in what directory should the profilemigrator.ini file be
> added?

The file is named "override.ini" and should be placed in the profile directory.

Comment 32

[Mike Kaply [:mkaply]]

(In reply to comment #31)
> (In reply to comment #30)
> > for verification - in what directory should the profilemigrator.ini file be
> > added?
> 
> The file is named "override.ini" and should be placed in the profile directory.
> 

Actually I made small change on this and people can shoot me if they want.

The override.ini needs to be in the same directory as firefox.exe.

The reason for this was because I realized that someone might be installing Firefox on a machine that never had Firefox and there needs to be a way to put the override.ini down as part of the install - so the profile directory doesn't work....

Comment 33

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #32)
> Actually I made small change on this and people can shoot me if they want.
> 
> The override.ini needs to be in the same directory as firefox.exe.

Why was this change made only on the branch? The trunk still uses the profile directory.

Comment 34

[Mike Kaply [:mkaply]]

(In reply to comment #33)
> (In reply to comment #32)
> > Actually I made small change on this and people can shoot me if they want.
> > 
> > The override.ini needs to be in the same directory as firefox.exe.
> 
> Why was this change made only on the branch? The trunk still uses the profile
> directory.
> 

Just haven't had a chance. Plan is to land that small fix on the trunk this weekend.

Also in 1.8.1

Comment 35

[Florian Effenberger]

This one works fine, however, what I'm still missing is an option to disable opening www.mozilla-europe.org on upgrading.

When I upgrade FF from 1.5.0.1 to 1.5.0.2, every user opening FF will be led to www.mozilla-europe.org the first time.

Comment 36

[Mike Kaply [:mkaply]]

This can be accomplished with the CCK:

http://www.mozilla.org/projects/cck/firefox

Comment 37

[Varun]

in the file http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/browser-region/region.properties
change line 17 to
startup.homepage_override_url=<your preferred homepage url>
then build or simply update en-US.jar or en-US.xpi
for complete deployment guide see http://varun21.blogspot.com

(In reply to comment #36)
> This can be accomplished with the CCK:
> 
> http://www.mozilla.org/projects/cck/firefox
> 

Comment 38

[Varun]

conclusion: to disable profile migration on browser first run or on creation of new profile, place a file called override.ini the contents of which read: (copy everything between the lines, excluding the lines.)
----------------------------------------
[XRE]
EnableProfileMigrator=false
----------------------------------------

Comment 39

[Ing-Long Eric Kuo]

Attachment: Additional patch using preference setting

I propose an additional fix which will be easier to use with the CCK.

a config item called "profile.enable_profile_migration", type boolean.

This patch goes right after the other patch.

Comment 40

[Ing-Long Eric Kuo]

Attachment: Additional patch using preference setting

I propose an additional fix which will be easier to use with the CCK.

a config item called "profile.enable_profile_migration", type boolean.

This patch goes right after the other patch.

Comment 41

[Ing-Long Eric Kuo]

Arg, I messed the patch again,

profile.enable_profile_migration.enable should be profile.enable_profile_migration

Comment 42

[Mike Kaply [:mkaply]]

See comment 12:

> mkaply, that hunk of code runs before we load extensions and prefs (we must not
> load prefs before running most of the profile migrators), so something that uses
> the pref service is really out of the question. Checking for the existence of a
> special file in the installdir is what I was thinking.

The only way to use this in a CCK top setting if you used the installer anyway, so you can lay down this file with the installer.

I can document how to do that.

Comment 43

[Daniel Veditz [:dveditz]]

Is this change needed on the 1.8 branch as well?

Comment 44

[Mike Schroepfer]

Please nom the appropriate patch for 1.8.1

Comment 45

[Mike Kaply [:mkaply]]

Attachment: Patch for 1.8 branch

This is the patch as baked in the trunk and 1.8.0 branch