Closed Bug 24911 Opened 25 years ago Closed 25 years ago

[PP]Profile picker shows no profiles

Categories

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

x86
All
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: michaell, Assigned: sspitzer)

References

Details

(Whiteboard: [PDT+])

In the 1/24 builds (has happened with both so far)

1) Delete my mozregistry.dat file.
2) Install seamonkey.
3) When the profile picker / migrator launches, it does not display any 
profiles.  I have several that I use with 4.x, and these have always been 
displayed.
4) If I click just under the "Available..." title, a line 1 pixel wide gets 
highlighted and "start mozilla" is activated.  Starting now works, but I don't 
get the profile I wanted (unlucky me).

The first time I tried to install this morning, I didn't blow away my 
mozregistry.dat file, and I noticed the same problem.
Marked as dogfood because I can't get at my user data.
Keywords: dogfood
Using -installer or -ProfileManager options does not show profiles to select as 
before- but seems to be confined to Win builds - Mac and Linux still behaving as 
before.

mozilla -SelectProfile will show 4.x profiles-the only way I could get migration 
to work today.
OS: Windows NT → All
Summary: Profile picker shows no profiles → [PP]Profile picker shows no profiles
oops, seeing this on Linux too
sorry for confusion-had m13 build before
here's what's supposed to happen:

unmigrated profiles are shown only in the Profile Manager, not in the Selection 
dialog. This is by design - to avoid the clutter of profiles that aren't useful 
in this version of of the browser.

On first launch, I'm not sure what the strategy is (but it's most likely a back 
end strategy)... I'd assume something like this should happen:

First launch:
- look for 5.0 profiles. none (obviously, first launch).
- look for last used 4.x profile, ask to migrate it (and optionally all other 
profiles), or create a new profile. The selection dialog should NOT be shown at 
this stage, at least not until there is more than one 5.0 profile. 

Now that the back button is completely removed from the manager, there is no way 
to reach the profile selection dialog other than by having more than one profile 
or invoking any available command line switches.

My experience has been that initial loads of Mozilla have just loaded the CPW, 
which is similar to 4.x, but possibly not the best solution. (see above).

cc'ing seth who probably knows more about this than me.
The problem is that when I first tried to launch todays build, I hadn't blown 
away my mozregistry.dat file and I had a 5.0 profile.  The profile picker didn't 
display it.
*** Bug 24981 has been marked as a duplicate of this bug. ***
you had a single 5.0 profile? the Profile Selection dialog shouldn't be 
displayed at all in that case other than by cmdline switch. Why it doesnt show 
then is a mystery to me, will investigate how this is affected by my changing 
the selection/mgr to use gayatri's new i18n friendly profile retrieval 
mechanism.
m14

Target Milestone: M14
Putting on PDT+ radar for beta1/dogfood.
Keywords: beta1
Whiteboard: [PDT+]
Just wanted to mention that ever since around 1/24 the profile manager hasn't
been showing only 4.x profile that are ready for migration. And there appears to
be no way to view this list. Occasionally clicking on parts of the window will
activate the start mozilla button, then it will start to migrate a profile (not
sure how it picks it, but it just randomly picks one and migrates it.)
I checked in a fix that fixes some of the problems.

the current behaviour is *almost* fixed (at least for winnt and linux, haven't
tried mac)

here's what I see:

if I run -SelectProfile, all my 5.0 profiles show up.  if I then click on the
"Manage Profiles" button, the 4.x unmigrated ones show up, and they are
"dimmer".

I say that is "working" and what we intended.

if I run -ProfileManager, only my 5.0 profiles show up, and not my 4.x profiles.

I say that is "broken".

the profile list is coming over into js now.  before my checkin, when we called
profile.getProfileList() we'd get back "".

I added a dump statement to shows that it is working.

now the bug really belongs to ben.
Seth, Ben: I don't see how Seth's fix helps the person who wants to migrate 4.x 
profiles.

I wanted to test the migration code (and pick up some new filters I had set in 
the 4.x mail client), so I blew away mozregistry.dat and renamed the existing 
Users50 directory. Upon installation of a new build of the client (I think I 
tried this with the build on Jan 27th), I was not given the chance to migrate 
4.x profiles. I checked again using today's build (2000-01-31-11) on Windows NT, 
and had no opportunity to migrate.
*** Bug 25985 has been marked as a duplicate of this bug. ***
In duplicate of bug, someone noted that the profiles get listed if manager is 
started as -mail (probably assuming already exist muliple 5.x so as to load 
manager... can anyone confirm this?)
also this is highly associate with bug 25274, not willing to mark either as 
duplicate right now, both have good info about the same problem.. they probably 
should be linked combined??
sol:

my checkin was only part of the fix.

the real fix is coming (or will come from) hyatt and ben

right now, if you have multiple 4.x profiles, it will appear like you have none
when you start 5.0 for the first time.

they are not showing up, but they are there (they are tree rows one pixel high).
*** Bug 25972 has been marked as a duplicate of this bug. ***
right, so the cells that contain the profiles are 1px high. 

this doesnt sound like a ben bug, sounds like a weird tree bug. 
hyatt! watchew doin' boy? 
Assignee: ben → hyatt
Status: NEW → ASSIGNED
I suspect you're building cells with values of "".  Not convinced this is my bug 
guys.  Verify this, and if you still see it even when setting non-empty string 
cell values, you can give it back to me.

Assignee: hyatt → sspitzer
Status: ASSIGNED → NEW
this got fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
build 2000020809 looks good
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.