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

RESOLVED FIXED in Firefox 2 beta2

Status

()

Firefox
Migration
P4
enhancement
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Guido Günther, Assigned: bsmedberg)

Tracking

({fixed1.8.0.2, fixed1.8.1})

Trunk
Firefox 2 beta2
fixed1.8.0.2, fixed1.8.1
Points:
---
Bug Flags:
blocking1.8b5 -
blocking-firefox2 +
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tcn-dl])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
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

12 years ago
*** Bug 286711 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 2

12 years ago
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

12 years ago
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

Comment 4

12 years ago
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.
(Assignee)

Comment 5

12 years ago
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)

Updated

12 years ago
Flags: blocking-aviary1.1? → blocking-aviary1.1+

Comment 7

12 years ago
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. ***

Updated

12 years ago
Flags: blocking1.8b4+
(Assignee)

Updated

12 years ago
Priority: -- → P4
(Assignee)

Comment 9

12 years ago
I'm not going to get to this for 1.1
Flags: blocking1.8b4-
Flags: blocking1.8b4+
Flags: blocking-aviary1.1+

Comment 10

12 years ago
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

12 years ago
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?
(Assignee)

Comment 12

12 years ago
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.
(Assignee)

Comment 13

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

Comment 14

12 years ago
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

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

Comment 16

12 years ago
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

12 years ago
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

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

Comment 19

12 years ago
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

12 years ago
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

12 years ago
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.
(Assignee)

Comment 22

12 years ago
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

12 years ago
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

12 years ago
Created attachment 208383 [details] [diff] [review]
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

Updated

12 years ago
Attachment #208383 - Flags: review?(benjamin)
(Assignee)

Comment 25

12 years ago
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+

Updated

12 years ago
Attachment #208383 - Flags: superreview?(tor)

Comment 26

12 years ago
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
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 27

12 years ago
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?

Updated

12 years ago
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+

Updated

12 years ago
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.

Comment 32

12 years ago
(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.

Comment 34

12 years ago
(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

11 years ago
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

11 years ago
This can be accomplished with the CCK:

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

Comment 37

11 years ago
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

11 years ago
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

11 years ago
Created attachment 220753 [details] [diff] [review]
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

11 years ago
Created attachment 220756 [details] [diff] [review]
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.
Attachment #220753 - Attachment is obsolete: true

Comment 41

11 years ago
Arg, I messed the patch again,

profile.enable_profile_migration.enable should be profile.enable_profile_migration

Comment 42

11 years ago
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?

Comment 44

11 years ago
Please nom the appropriate patch for 1.8.1
Flags: blocking-firefox2? → blocking-firefox2+

Comment 45

11 years ago
Created attachment 228441 [details] [diff] [review]
Patch for 1.8 branch

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

Updated

11 years ago
Attachment #228441 - Flags: approval1.8.1? → approval1.8.1+

Updated

11 years ago
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.