Closed Bug 27850 Opened 25 years ago Closed 25 years ago

[regression]2000.02.15.09 4.x profiles are not appearing

Categories

(SeaMonkey :: Startup & Profiles, defect, P3)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jlarsen, Assigned: racham)

References

Details

(Whiteboard: [PDT+] 2-21-00)

once again, just starting today in 2000.02.15.09 4.x profiles (specifically 4.7 on test computers) are not appearing in the profiles available for migration. Need to figure out why this keeps breaking.??
mozilla -installer which launches from an install brings up ProfileManager but does not display 4.x profiles on Win and Linux the other options (mozilla -ProfileManager etc) are working
My added info: -profilemanager takes 2-3 launches before displaying the (4.x) profiles for migration if you've removed registry.
Alright, correct me if I'm wrong here, but this is what seems to be happening. If you run mozilla -installer and there is no registry. It creates an empty registry during loading. And then runs the profilemanager. Which having no registry to go on, does not properly display the old 4.x profiles. (but creates a working registry upon exit) If there is a registry, and there is no profiles, -installer creates a default profile without any questions (this is not what is wanted is it?) and starts the browser. If you run mozilla -ProfileManager, and there is no registry. it does the same thing as installer and creates and empty registry, and runs the profilemanager which doesn't work and creates a registry on exit. plain mozilla opens the create new profile wizard if there is not a profile, no mater what the registry settings are.. this is correct I beleive??.
Summary: 2000.02.15.09 4.x profiles are not appearing → [regression]2000.02.15.09 4.x profiles are not appearing
*** Bug 28123 has been marked as a duplicate of this bug. ***
adding beta 1 keyword to this and other related bugs (28025,282340,27402) for PDT consideration
Keywords: beta1
*** Bug 28234 has been marked as a duplicate of this bug. ***
this seems PDT+ to me. I see that ben has a lot of pdt+ bugs, and I've got one. (racham has 3, gayatrib has 2, one is making the profile manage i18n friendly, which is a bigger task.) perhaps I can take this one?
adding me to the cc list.
*** Bug 28025 has been marked as a duplicate of this bug. ***
Seth, Ben isn't back until Monday afternoon, so I'm assigning this to you in hopes you can help us out. Thanks.
Assignee: ben → sspitzer
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
marking m14, accepting, hoping to fix this weekend.
Status: NEW → ASSIGNED
Target Milestone: M14
Seth, From what I see, profile manager/selector used to get the list of profiles via a (comma separated) string and then split the list and display those items and add them to the tree widget. This string with profile names is provided by GetProfileList of nsProfile.cpp. This list is provided fromthe internal nsVoidArray (nsProfileAccess.cpp) that maintained the list of profiles. Ben's recent changes stopped using GetProfileList and tap the registry directly for the values. The plan was to not to make that change until we finish i18n. That could have caused this problem. In the second run you will all the profiles getting listed as registry all those values by then. So, I am thinking we should call UpdateRegistry as soon as the migrate profile information part is done so that info gets written into the registry before javascript taps the registry.
re-assign to racham. I'm testing his fix now.
Assignee: sspitzer → racham
Status: ASSIGNED → NEW
Whiteboard: [PDT+] → [PDT+] 2-21-00
Status: NEW → ASSIGNED
Registry updates were missing. Fixed now.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
build 2000022208
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.