399790 - Profile List comes up blank after creating new profiles

Status: RESOLVED FIXED

(SeaMonkey :: Startup & Profiles, defect)

Description

[Mark Banner (:standard8)]

Attachment: Possible Fix

Using trunk self build from 13 Oct 07

Steps to reproduce:

1) Start with no profiles in ~/.mozilla/seamonkey
2) Start up SeaMonkey and migrate from an existing profile (may not have to migrate to reproduce this bug).
3) Exit SeaMonkey
4) ./seamonkey -createProfile test
5) ./seamonkey

At step 5 the profile manager is shown with no entries. Console shows:

JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIToolkitProfileService.selectedProfile]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://communicator/content/profile/profileSelection.js :: StartUp :: line 76"  data: no]


I'd expect it to either start up with the profile created at step 2 or show the profile manager with the proper profile list.

Analysis of profiles.ini for working & non working builds reveals that StartWithLastProfile=1, but neither of the two profiles have "Default=1" on them. This causes the assertion above.

Possible fix attached. I'm not sure if this is the correct/complete one or not, as like I said above - I'm not sure if at step 5 I'd expect it to start with the profile created in step 2 (as I think the old profile manager did).

Comment 1

[[e-mail]]

Comment on attachment 284857 [details] [diff] [review]
Possible Fix

Whoops, I accidentally lost the comment... although I don't think this is a SeaMonkey bug (because profile creation is part of toolkit) I think it's worth catering for this case anyway.

>+  var selectedProfile;
I'd init this to null here, making the catch assignment redundant.

Comment 2

[Mark Banner (:standard8)]

(In reply to comment #1)
> (From update of attachment 284857 [details] [diff] [review])
> Whoops, I accidentally lost the comment... although I don't think this is a
> SeaMonkey bug (because profile creation is part of toolkit) I think it's worth
> catering for this case anyway.

Checked in with nit addressed. I'll have a search around tomorrow to see if there is a toolkit bug covering the default part of this.