User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8a2) Gecko/20040625 Build Identifier: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7) Gecko/20040629 Firefox/0.9.1 I have always deleted Firefox profiles are earlier tests. Starting FF 0.9.1 still gives me the option to import those. But when doing so, it does not discover, that this profile does not exist, and hangs. Reproducible: Always Steps to Reproduce: 1. Delete old FF profile 2. Start FF 3. Select import FF/FB/Phoenix profile, proceed Actual Results: Import wizard hangs on next page, but FF continues starting after closing it. Expected Results: An error message "Selected import profile does not exist" (or something like that) should have appeared. This is similar to bug 246596, but FF does not crash and this is only for old FF profiles.

A one line patch to fix this. I guess it the Phoenix migrator should also be hidden, as there is a routine after this that searches for known profiles to import. I cannot test this on OS/2, because it seems that Firefox looks for the old profiles in different areas than e.g. Firefox 0.8 writes them. That probably is a different bug...

How are you deleting the old profile?

I also see this behaviour on Linux. There I did rm -rf ~/.phoenix after running earlier versions. After running Firebird-0.x/fox-0.8 (without MOZILLA_HOME) on OS/2 I removed the Profile directory inside the installation dir (WPS delete or rm -rf Firefox or rm -rf Mozilla). I can also see that my "fix" does not fix this problem. Instead it does not offer the Phoenix import at all any more. Seems that the code commented as // Figure out what source apps are are available to import from does not do search for this type of profile.

Confirmed this bug. This is rather embarrassing when installing Firefox on a brand new WinXP system. There was nothing to import at that time so I selected 'import from firefox' and then it just stopped working. This was with the 0.9.2 release installer.

Asa and I are seeing this with recent builds. Also, migrating the "non-existant" Firefox data no longer hangs, but instead migrates IE data.

We shouldn't be showing the Phoenix/Firebird/Firefox migration option if the user never had Phoenix/Firebird/Firefox installed. Is it possible that we're creating a Firefox profile folder before Migration gets kicked off and then we're seeing our own new profile?! This has got to be fixed before 1.0.

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

Mac hangs in "Following items are being imported message window the the import wizard on trying to import from Fire*something* when it doesn't exist. Must force quit to get out.

Comment on attachment 152065 [details] [diff] [review] set phoenix.hidden=true initially Hiding the items is done later in a loop that calls "GetSourceExists" on each migrator... sounds like the Phoenix Migrator is lying... that's where this should be fixed.

add "fromfile" to the exclusion conditions.

br & trunk fixed.

FIXED br & trunk.

looks like it has been fixed on the branch, so could somebody please add the fixed-aviary1.0 keyword? (i know this is trivial but it would be useful for querying the overall number of remaining bugs)

Migration is still offering Firefox 0.8, Firebird, Phoenix as a choice. Seen on a clean install on a new user profile on Mac build 2004-09-29-06-0.9. I installed and launched Mozilla to get an available profile for migration. There isn't any instance of avairy anything on this machine, except the Firefox build that I just installed and launched with. The fix for this bug was check in just after midight. So this build should reflect the change, but it doesn't. reopening and will double check on Windows when that build when it becomes a available

Still on Windows Firefox branch build 2004-9-29-09-0.9

also, make sure the wizard's first page's onpageshow handler is not called before onload, guard against showing phoenix item in list in non-automigrate cases too.

OK, fixed again, br & trunk.

verified with Mac and Windows branch builds on 0930 with clean installs