Closed Bug 286557 Opened 16 years ago Closed 15 years ago

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

Categories

(Firefox :: Migration, enhancement, P4)

enhancement

Tracking

()

RESOLVED FIXED
Firefox 2 beta2

People

(Reporter: agx, Assigned: benjamin)

References

Details

(Keywords: fixed1.8.0.2, fixed1.8.1, Whiteboard: [tcn-dl])

Attachments

(3 files, 1 obsolete file)

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)
*** Bug 286711 has been marked as a duplicate of this bug. ***
Sorry this got filed twice, no idea though how this happend. The config option
below should read:
general.config.filename
not
config.config.filename
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
Summary: No way to configure that Import Wizard should be skipped on first startup → Need an easy way to skip/disable/turn off the Import Wizard on first startup (when no profile exists)
Version: unspecified → Trunk
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.
Putting on the radar, but no guarantees. Patches are very welcome!
Flags: blocking-aviary1.1?
Target Milestone: --- → Firefox1.1
Forced migration was implemented in Thunderbird, in bug 291259.
Component: Startup and Profile System → Migration
Summary: Need an easy way to skip/disable/turn off the Import Wizard on first startup (when no profile exists) → Need an easy way to skip/disable/turn off the Import Wizard (profile migration) on first startup (when no profile exists)
Flags: blocking-aviary1.1? → blocking-aviary1.1+
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   |    |
|                                     +----------+    |
+-----------------------------------------------------+
*** Bug 264464 has been marked as a duplicate of this bug. ***
Flags: blocking1.8b4+
Priority: -- → P4
I'm not going to get to this for 1.1
Flags: blocking1.8b4-
Flags: blocking1.8b4+
Flags: blocking-aviary1.1+
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.
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?
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.
*** Bug 305617 has been marked as a duplicate of this bug. ***
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.
for my reference (as a potential embedder), can i choose not to build the 
migrators?
The migrators are app-specific, so they should not affect embedding unless you
are trying to embed firefox instead of just the platform.
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 ...
I think you can define XRE_IMPORT_PROFILES=1 in your environment to disable
profile migration.
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.
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?
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.
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).
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;
Attached patch Complete fixSplinter Review
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
Attachment #208383 - Flags: review?(benjamin)
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).
Attachment #208383 - Flags: review?(benjamin) → review+
Attachment #208383 - Flags: superreview?(tor)
Fix checked in.

This bug as written is fixed.

If we want to actually customize the import, I believe that is a separate bug.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
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.
Attachment #208383 - Flags: superreview?(tor) → approval1.8.0.2?
Flags: blocking1.8.0.2?
Not blocking a security release, might approve the patch
Flags: blocking1.8.0.2? → blocking1.8.0.2-
Comment on attachment 208383 [details] [diff] [review]
Complete fix

approved for 1.8.0 branch, a=dveditz
Attachment #208383 - Flags: approval1.8.0.2? → approval1.8.0.2+
Flags: blocking1.8.0.2- → blocking1.8.0.2+
Keywords: fixed1.8.0.2
for verification - in what directory should the profilemigrator.ini file be added?
Whiteboard: [tcn-dl]
(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.
(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....
(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.
(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
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.
This can be accomplished with the CCK:

http://www.mozilla.org/projects/cck/firefox
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
> 
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
----------------------------------------
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.
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.
Attachment #220753 - Attachment is obsolete: true
Arg, I messed the patch again,

profile.enable_profile_migration.enable should be profile.enable_profile_migration
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.
Is this change needed on the 1.8 branch as well?
Flags: blocking-firefox2?
Please nom the appropriate patch for 1.8.1
Flags: blocking-firefox2? → blocking-firefox2+
This is the patch as baked in the trunk and 1.8.0 branch
Attachment #228441 - Flags: approval1.8.1?
Target Milestone: Firefox1.5 → Firefox 2 beta2
Attachment #228441 - Flags: approval1.8.1? → approval1.8.1+
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.