Profile List comes up blank after creating new profiles

RESOLVED FIXED in seamonkey2.0a1

Status

SeaMonkey
Startup & Profiles
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: standard8, Assigned: standard8)

Tracking

Trunk
seamonkey2.0a1
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.03 KB, patch
neil@parkwaycc.co.uk
: review+
neil@parkwaycc.co.uk
: review+
neil@parkwaycc.co.uk
: superreview+
Details | Diff | Splinter Review
(Assignee)

Description

11 years ago
Created attachment 284857 [details] [diff] [review]
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).

Updated

11 years ago
Attachment #284857 - Flags: superreview+
Attachment #284857 - Flags: review+

Comment 1

11 years ago
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.
Attachment #284857 - Flags: review+
Assignee: nobody → bugzilla
(Assignee)

Comment 2

11 years ago
(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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED

Updated

11 years ago
Target Milestone: --- → seamonkey2.0alpha
You need to log in before you can comment on or make changes to this bug.