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)
Tracking
(Not tracked)
VERIFIED
FIXED
M14
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.??
Comment 1•25 years ago
|
||
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??.
Comment 4•25 years ago
|
||
also bug 28025
Summary: 2000.02.15.09 4.x profiles are not appearing → [regression]2000.02.15.09 4.x profiles are not appearing
Comment 6•25 years ago
|
||
adding beta 1 keyword to this and other related bugs (28025,282340,27402) for
PDT consideration
Keywords: beta1
Comment 8•25 years ago
|
||
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?
Comment 9•25 years ago
|
||
adding me to the cc list.
Comment 10•25 years ago
|
||
*** Bug 28025 has been marked as a duplicate of this bug. ***
Comment 11•25 years ago
|
||
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
Comment 13•25 years ago
|
||
marking m14, accepting, hoping to fix this weekend.
Status: NEW → ASSIGNED
Target Milestone: M14
Assignee | ||
Comment 14•25 years ago
|
||
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.
Comment 15•25 years ago
|
||
re-assign to racham. I'm testing his fix now.
Assignee: sspitzer → racham
Status: ASSIGNED → NEW
Whiteboard: [PDT+] → [PDT+] 2-21-00
Assignee | ||
Comment 16•25 years ago
|
||
Registry updates were missing. Fixed now.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•