User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 Mnenhy/0.7.5.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007091304 SeaMonkey/2.0a1pre I tested migrating a Mozilla Suite 1.7.x profile (Created around 1.7.x, used up to 1.7.12) to Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007091304 SeaMonkey/2.0a1pre The following prefs where not migrated: plugin.expose_full_path - true update_notifications.enabled - false There is also an issue withe migrating the default homepage. Profile migrator showed up with one radio button and no text/url next to it. Just [] in a very small font - guessing 4 or 6 pt. browser.startup.homepage is set to server.internal.xxxxx-yyyyy.de First guess was that the url wasn't recognized cos of missing http:// or www but failed also with adding them. It failed even with http://www.seamonkey.at I did another test with migrating a Seamonkey 1.1.4 profile, with no default home page. Migration failed the same way and default home page was set to http://www.mozilla.org/projects/seamonkey/start/ Reproducible: Always

I think we should not migrate update_notifications.enabled from anywhere, as we're completely dumping the update notification system, and I really want the new auto-update feature to be enabled by default for anybody, as it works completely differently. Those people who disabled the notifications because of the annoying popup and needing to download a full version again will get something completely different which they might like (once we have that feature enabled). Those people who disabled it because they don't want us to poll our server can easily re-disable it, but disabling it is a security risk after all, so I don't want to make us too eager in disabling. Additionally, this _defaulted_ to off for 1.7 (which IMHO was bad) and we really want to default the new auto-update service to on in the future. The default homepage thing is surely something to look into - not sure what the plugin pref you cite is for.

(In reply to comment #0) > plugin.expose_full_path - true > update_notifications.enabled - false I've just checked in a patch on bug 382495 that fixes the plugin.expose_full_path prefs (and another plugin pref that had been missed from the SeaMonkey migrator). I agree with Robert's comments about the update_notifications pref. That leaves just the homepage migration issue. I'm setting the OS to windows as you've only specified that you've tested it on windows and I'm not seeing it on Linux, so it could be an os specific issue. > There is also an issue withe migrating the default homepage. > Profile migrator showed up with one radio button and no text/url next to it. > Just [] in a very small font - guessing 4 or 6 pt. I don't see this issue unfortunately (on Linux). Can you repeat the migration (maybe into a new profile, see http://wiki.mozilla.org/SeaMonkey:New_for_2.0 for how to do this into a new profile), and when the browser starts up, see if there is anything in the Error Console? (tools->error console). I'm not sure if there will be, but its my only thought as to finding the problem at the moment.

update_notifications was turned off, coz this profile was used in an office environment and updates are done by an admin. Also there was not working update / notification system with Mozilla Suite. I agree that autoupdates should be enabled by default. I repeated the migration (just deleting the migrated one) also with some other Seamonkey profiles. The tested Seamonkey profiles raised no error. With the 1.7.x profile i get following Error: Error: [Exception... "'Illegal value' when calling method: [nsICommandLine::handleFlagWithParam]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: file:///C:/temp/download/seamonkey-2.0a1pre.en-US.win32-07-09-13/components/nsBrowserContentHandler.js :: handle :: line 387" data: no] Source File: file:///C:/temp/download/seamonkey-2.0a1pre.en-US.win32-07-09-13/components/nsBrowserContentHandler.js Line: 387 But this is another issue. This profiles has general.startup.mail = true and Mail/News is querying an Server not available. However, with general.startup.mail = false and opening Mail/News manually i don't get this error. Mail/News still trying to connect and failing. Importing the homepage works with Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a7pre) Gecko/200707060303 SeaMonkey/2.0a1pre the last one floating around here. This Build is also raising the exception. Just tried another one, broken in: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007082903 SeaMonkey/2.0a1pre

(In reply to comment #0) > First guess was that the url wasn't recognized cos of missing http:// or www > but failed also with adding them. It failed even with http://www.seamonkey.at > I did another test with migrating a Seamonkey 1.1.4 profile, with no default > home page. Migration failed the same way and default home page was set to > http://www.mozilla.org/projects/seamonkey/start/ Just to confirm, when you say the default home page was set to http://www.mozilla.org/projects/seamonkey/start/ - did you check that it is that url via the preferences dialog or via clicking the home button? The start page (brought up on first run of profiles in a new version of SM) is different to the home page. Having just got confused about it when talking to someone on irc about this bug, I'm wondering if this is the confusion here.

I don't use the home button, usually he's disabled. http://www.mozilla.org/projects/seamonkey/start/ is the url in the preferences dialog and also the startpage after the first start of seamonkey. I verified this again with build 2007091304. This url is also used as startpage and Seamonkey homepage with the working Build 200707060303 when selected to use default Seamonkey homepage during import.

last working Build is: Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007082702 SeaMonkey/2.0a1pre the next available win32 build is broken Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a8pre) Gecko/2007082803 SeaMonkey/2.0a1pre There is no win32 build in http://archive.mozilla.org/pub/seamonkey/nightly/2007-08-28-01-trunk/ Btw. Windows NT 5.0 is Windows 2000, not XP (5.1). I can try to verify this on XP tomorrow

like expected, same problem in WinXP as in Win2k

I've been able to reproduce the problem now. I'm working on a patch at the moment.

The failure case is because the target prefs.js doesn't exist at the time this check is made. So if it doesn't exist we definitely won't have a home page set in the target profile

Patch checked in -> This should be fixed now. If you can, please try tomorrow's nightly to confirm this.

I wasn't having profile problems until today. I had been stuck on a build from the end of August due to the bug where it wouldn't start up which was recently fixed. I ran a nightly build Friday 9/28/2007 on another machine which seemed fine. I ran the below build, and it asked me about importing a profile. I forgot how I answered it, but now I have two different profiles (I think the current one is an old profile). My newer, correct profile I think (going by the bookmarks) seems to still exist. I think the difference is the directories they are found in. If anything, this bug breaks the application for me, not fixes it. Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092902 SeaMonkey/2.0a1pre

No Bug, the profile location was changed back to mozilla. See Bug 393620, http://wiki.mozilla.org/SeaMonkey:Moving_Profiles_from_mozilla.org_to_Mozilla and the discussion in mozilla.dev.apps.seamonkey I'll try importing later.

Homepage migration now working with Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007093003 SeaMonkey/2.0a1pre