using branch build 2001062506- I am unable to install and launch with my one 4.x profile on Linux steps to reproduce: 1. remove .mozilla 2. install build or run with -installer option actual results: N6 hangs in 'inside migrate profile routine' second launch tries to migrate again (and again) workaround is to kill process and run with -profilemanager option. The 4.x profile shows as unmigrated but if you select and confirm-- it does get migrated expected results: migration completes and activation launched It does not happen with mozilla and should probably be in bugscape-but there is no profile component there

Grace, I think this is bugscape bug 5992. Closing this one.

this is somewhat different. in bug 5992, profile migrates, brings up empty activation etc in this bug I do not get beyond 'inside migrate profile' routine. Maybe the fix to 5992 will fix this but I would like to leave open until it does. I am getting too many calls on this

Moving Bugscape-bug 5992 to this bug per marc and ccarlen comments. This will fail on the 2001062706 mozilla branch build if the preference in the all.js file "profile.confirm_automigration" is set to false. By default this preference is set to true on the mozilla builds so you won't see this hang after initial install with your ~/.mozilla directory deleted. What is happening on the commercial builds is that the all-ns.js file has this preference set to false after initial install, and thus causing the hang...so I thought. Setting the "profile.confirm_automigration" pref to true in the all-ns.js file still shows the hang. Any ideas as to why the commercial builds still show this behavior after setting the pref "profile.confirm_automigration" to true in the all-ns.js file?

http://bugscape.netscape.com/show_bug.cgi?id=5992 was about the Activation window not showing up when profile migration happened from a 4.x profile (which happens when a 4.x profile exists and a mozilla profile does not). It could also be reproduced in Mozilla by setting the pref "profile.confirm_automigration" to false. The problem was that nsDeviceContextGTK was getting a prefChanged callback for its DPI pref value. Its |Init| method handled -1 (the default, which says use the OS only if the OS says it's greater than 96dpi) and 0 (which says to always use tho OS) values specially, but the codepath that handled them specially was not in the codepath for the prefChanged callback. Looking for reviews.

Nice refactoring of the pref value logic, and the general cleanup looks good too - [s]r=attinasi

r/sr=brendan@mozilla.org. /be

Fix checked into trunk 2001-06-28 19:59 PDT. Adding nsBranch keyword.

reassigning to dbaron who has the fix.

Will this bug make it to the branch as well? If not, how can I nominate it for consideration? The Solaris commercial port is suffering from this bug as well; it'd be nice to see the fix in commercial builds and Mozilla both.

I'll spam pdt2@netscape.com to get approval on this for the branch.

Looks like we got PDT approval...here is a snippet of my reply back from pdt2@netscape.com: >a=chofmann Please check into the branch.

Marking PDT+ per conversation with chofmann.

Checked fix into branch, 2001-06-30 12:01 PDT. gbush: Is there another bug open for the problem you were describing before this bug morphed? (Waiting to mark FIXED pending answer and potentially filing a separate bug if the other problem still exists.)

There was no other bug events transpired: bug 5992 was logged (at that point I could automigrate) but not get through activation on first launch- logged on 6/6 then the automigration failed and I logged this bug - 6/20 I will check with today's builds and comment here

I am not seeing this problem on branch ( or trunk) for 2001070206 0.9.2 or 2001070208 will be verifying bug 5992

OK, marking fixed then.

David, See bug 88893- some strange behavior coming up. Not sure if related

FYI, this is broken again in the branch and trunk starting july 3. July 2 is the only set of linux bits that will allow 4.x profile migration. This might be a result of bug 88893. Anybody else seeing this again?

Note: This is only happening on the commercial builds.

this is fixed on branch 2001070604 if using recommended install (or custom without Java), Profiles behave as expected, automigration takes place adding vtrunk

verified on trunk 2001081006