Open Bug 490009 Opened 11 years ago Updated 11 months ago

Migration wizard isn't launched after initial installation of Firefox

Categories

(Firefox :: Migration, defect, P3)

3.5 Branch
x86
Windows XP
defect

Tracking

()

People

(Reporter: whimboo, Unassigned)

Details

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4

While testing the Firefox 3.5 beta 4 release I noticed that the initial migration dialog isn't fired and we always start with a fresh profile. According to my knowledge we watch for a Firefox folder under %appdata% to decide if we have to show the migration wizard. But even with the folder deleted it doesn't come up.

This also affects all other instances of Firefox installed on the system. Means 3.1b3, 3.0.8, and 2.0.0.20. It gives an impression that something is broken for my system but I don't know where to look at. Tracy is also able to reproduce this problem.

Jim, do you know what that happens? What can we check to ensure that it's not our fault?
Flags: blocking-firefox3.5?
Flags: blocking-firefox3.5? → blocking-firefox3.5+
Priority: -- → P2
I recall there being bugs about strange behavior with the migration code on VM's... was this tested on a system that wasn't a VM?
Ok, some more information of several application versions:

* VmWare Fusion Version 2.0.4 (159196)
* Windows XP Professional Version 2002 SP3

I could swear that it was working fine before I have installed SP3 a couple days ago. The last smoketest for Firefox 3.1 beta 3 passed and I haven't seen this problem.
I'm not using a VM and can reproduce this. XP sp3
Tracy, for clarity can you verify by removing both the Mozilla directories under %LOCALAPPDATA% and %APPDATA%
I just checked on Vista after removing both of the directories as stated in comment #4 and the migration wizard was shown with
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b5pre) Gecko/20090423 Shiretoko/3.5b5pre

I highly suspect this is an issue that only affects VM's. I also suspect that this is due to simulating migration by deleting the directories and it wouldn't affect a clean VM.
yes, I've made a comprehensive sweep of all the "mozilla" folders in those directories for all user profiles on this machine.

I ran into this sort of bug a year or so ago. it had to do with having opera or seamonkey set as the default browser. but now I'm just IE or Fx default.
(In reply to comment #4)
> Tracy, for clarity can you verify by removing both the Mozilla directories
> under %LOCALAPPDATA% and %APPDATA%

Under the VM I have deleted both folders but without success. It's a new behavior I hadn't before. I checked the test results for the latest releases.
Let's separate this out so the VM issue is in the original bug 415968 and Tracy's issue is in this bug.

(In reply to comment #7)
> yes, I've made a comprehensive sweep of all the "mozilla" folders in those
> directories for all user profiles on this machine.
As long as comprehensive sweep means you opened %LOCALAPPDATA% and %APPDATA% and deleted the mozilla directories in both of these locations then this is new behavior and I am unable to reproduce with Firefox as default as stated in comment #5. Also, you aren't using Parallels... true?
I just checked on beta 4 and it's launching. On a stand alone machine all you have to do is rename your existing fx app data directory to retrigger it - 

C:\Users\(username)\AppData\Roaming\Mozilla

changed to 

C:\Users\(username)\AppData\Roaming\Mozilla-

and Fx will bring it up again. This is on Vista.
I was also unable to reproduce on Vista with the latest Opera, chrome, Safari, and IE8 set as the default browser using the steps I stated previously
Yes, no Mozilla folders anywhere.  

True, not running Parallels.  This is a dedicated XP box.

I've messed with this off and on for months on this XP Box. Done everything I can think of short of mucking in reg keys or completely wiping the system.
Could someone from QA try to reproduce this on the XP systems in the QA lab? I'd like to get an idea if this is due to a difference in the system configuration or applies to all XP systems along with having a system I or someone else can work with where this bug can be reproduced?
Keywords: qawanted
I will try on the machine in the QA lab and report back...
I can reproduce this in the lab using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4. 

I first deleted all data from %APPDATA%, but%LOCALAPPDATA% file could not be found on this system. I also uninstalled all other versions of Firefox that were running side by side as well.

Luckily I also have another XP laptop where I can try this as well, that is a bit less crufty.
Using the Win XP laptop which is running XP SP 2, I tried to delete the %APPDATA% directory, but unfortunately I get an error which states "Cannot delete history.dat: It is being used by another person or program. Close any programs that might be using the file and try again." No other programs are running and I get the same error even after rebooting.

But I do get the migration wizard on this machine after the installing.
Also note, everyone should be testing with fully branded builds, not nightlies. (see bug 489904)
(In reply to comment #17)
> Also note, everyone should be testing with fully branded builds, not nightlies.
> (see bug 489904)

Actually scratch that, that just disables one screen. the migrator should still come up on nightlies.
All that's really required is removing/renaming the profiles.ini file.  If this isn't getting deleted, we won't get the the dialog.  We have moved some files, so it's not clear that everyone's finding this file... wondering if QA is checking under /Roaming ?
marcia, is the lab machine that you can reproduce this on Win XP sp3?
Minusing for now, since it doesn't seem clear that it's actually happening, please renominate if we can get confirmed STR after nuking the \Roaming dir as well.
Flags: blocking-firefox3.5+ → blocking-firefox3.5-
Tracy, do you still see this problem? Could you try the same steps with another Windows user account? Does it still happen under such a condition?
I can reliably reproduce this on my XP sp3 box with any user account. I completely remove any instances of the "Mozilla" folder from all accounts in both C:\Documents and Setting\<user>\Application Data\ and C:\Documents and Setting\<user>\Local Settings\Application Data\ on each account.  I've searched for Roaming on XP to no avail. Is that a Vista thing? 

I can reproduce with nightly builds and release builds.

Marcia, we're you able to reproduce on an XPsp3 box in the lab?
I've done everything I can to figure out why this happens, short of re-installing the OS.
Keywords: qawanted
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.