Closed Bug 120410 Opened 23 years ago Closed 20 years ago

Select a profile name and it is not highlighted

Categories

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

Product:
SeaMonkey
Component:
Startup & Profiles
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: nbaca, Assigned: neil)

References

(Depends on 2 open bugs)

Details

(Keywords: regression, testcase, verified1.7)

Attachments

(13 files, 4 obsolete files)

Screen Capture of non-highlighted profile
132.87 KB, image/bmp
Details
registry.dat (after comment 62), requested by comment 63
5.71 KB, application/octet-stream
Details
The file with the problem
3.21 KB, application/octet-stream
Details
Proposed patch [Checked in: Comment 100]
549 bytes, patch
roc
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review
Screenshot of non-highlighted profile (original problem)
23.89 KB, image/jpeg
Details
4 Screenshots showing new problem
92.08 KB, image/jpeg
Details
Supplemental patch
1.08 KB, patch
janv
: review+
mscott
: superreview+
Details | Diff | Splinter Review
testcase
2.00 KB, application/vnd.mozilla.xul+xml
Details
testcase
716 bytes, application/vnd.mozilla.xul+xml
Details
registry.dat which shows problem
88.09 KB, application/octet-stream
Details
Possible branch band-aid
2.24 KB, patch
janv
: review+
alecf
: superreview+
chofmann
: approval1.7+
Details | Diff | Splinter Review
Icons to close to profile names in classic theme
22.58 KB, image/jpeg
Details
Pad out the image
11.95 KB, patch
janv
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review 
Trunk build 2002-01-15-03:WinMe

Overview: Select a profile from the Profile Manager list and it is not
highlighted.This only happens for the profile that was just previously used.

Steps to reproduce: 
1. Have atleast 2 profiles displayed in Profile Manager
2. Select "profile1" and start the app
3. Exit 
4. Double click the *.exe file so that Profile Manager appears again

Actual Results: 
* Notice that no profile is selected, when profile1 should be selected.
5. *Select the first profile (profile1) and it still does not appear
highlighted. Start the application and it launches the correct profile.
6. Exit, restart and now select the second profile (profile2) and it is highlighted.
7. *Exit, restart and again no profile is selected, when profile2 should be
selected.
8. *Try selecting profile2 and it is not highlighted
9. Try selecting profile1 and it Now appears highlighted

Actual Results Summary: It appears that the previously used profile is the one
that does not display a highlight when selected in the profile manager list. 

Expected Results: Selecting a profile name in the Profile Manager List should
highlight the selection in all cases. Including the last/previously used profile.
Marking nsbeta1 because this is confusing.
Keywords: nsbeta1
*** Bug 120063 has been marked as a duplicate of this bug. ***
from my dupe, also try my testcase, as I have several profiles, one from each build.

This is a regression started with build 1-14-03 w2k, It works in 1-11-03 build,
I see that trying to select one the last listed profile, the profile picker
selection bar is not visable, but you can start mozilla in that profile.  My
testcase there is not the same as it is here, but I can reproduce this crazy
problem.
Keywords: regression
its also an issue in 1-17-03 w2k build.
This only happens to me when my last used profile is the last profile displayed 
in the profile manager.  

If my last used profile is not in the last row, everything worked fine.

I used 2002011803 trunk build on WinNT.
weird part is today, I decided to do manage profiles > 'delete' and deleted all
the profiles (I had probably 12 or so) except 2 I made with ns6.2 and one I
created with today's build 1-18-03 (w2k) and one I made with 1-17-03 build.. now
I dont see this problem.. so I must have a been a problem with either profile
picker itself when the RDF:li blocker problem hit about 1-14-02, or when a
profile was created it created a problematic line in the profile picker itself
and we say this..was crazy and strange.  

So after doing those steps above in this writing I almost certain I cannot
reproduce the problem anymore.  so wfm 1-18-03 w2k.
Grace, how many profiles existed before you also saw this problem?
I got the behavior back by doing this:

Like I said I create 1 profile with each build & its shortcut in a directory..
so what I did is:
1) created 4 new profiles with builds 1-14 call it 1-14, repeated with builds
1-8, 1-10,1-11.. 
2) open 1-14 build and use manage profile > delete the last added profile.. 
3) close profile manager
4) open it again using the 1-14 build, last line has the visual problem.. 
5) close profile manager open say build 1-19 and it still has the problem with
last line
and steps to reproduce using test case will work again.

Then follow my next comment and using 1-18 or 1-19 build delete what is left
from the 4 you added, 
1-8, 1-10, 1-11, 1-14 profiles.. you then cannot reproduce the original problem,
and it is gone again.
after doing those in previous comments, 

today I used build 1-22-03 to create a new profile:

named "2002-1-22", which I had used in build 1-14: "2002-1-14"

I had 7 profiles in my list before I created this 8th one.. I got this original
problem after the profile was created.  I then was unable to follow any testcase
using build 1-22, (didn't try the testcase for builds 1-14 like in comment #9)
or was unable to reproduce using similar steps in comment #9.

but I was able to get an invalid selection by just creating a new profile with
build 1-22 again, named "2002-1-22", but not by typing "default user" as the
profile name.
ok, I see this again with build 1-23-04 w2k, I have 7 previous profiles, so 7
seems like the magical one.. I then added an 8th profile with this build and I
can reproduce the testcase in the dupe of bug 120063 comment #2 of changing
profiles now, but I didn't delete any profiles as in comment #9 here.  So this
exists for sure, its weird.
I tried this one more time, I deleted all my profiles except 2 netscape profiles
and one I created with build 1-19.. then proceeded to add a new profile, one for
each new build again.. before today I had a total of 6 profiles, then when
adding a profile with build 2-1 I seen this problem on the seventh profile.


So their is either a magic 7 number here, or its related to the combination of
the profiles there, is there a chance this is a possible corruption in the
registry.dat file?
with only seven profiles I cannot reproduce the testcase, but on first load I
see this #7 profile is not highlighted, but doesn't happen after subsequent uses
of the profiles.. if I add an 8th one maybe I will be able to reproduce a testcase.


I created a new profile using build 2-2-08, it is the 8th profile in my list, it
now has the problem.. I think I can reproduce the testcase again.  


Any thoughts?
I think I can rule out corrupt registry.dat file, unless the current Profile
Manager code is creating a corrupt one itself.  I deleted all my profiles and
started from scratch to see if that was the case, I created a new one using
netscape 6.2.1, and seven new profiles with mixed numbers, dashes, & text, and
still found a problem with #8 not being highlighted.  So some code was changed
in the profile manager way back on the 13th, or 14th for the worse..about when
the RDF:li problem hit.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.2
*** Bug 124779 has been marked as a duplicate of this bug. ***
nsbeta1- per ADT triage team
Keywords: nsbeta1 → nsbeta1-
Setting as a blocker of bug 123929, safeguard against profile corruption 
tracking bug.

How big is your registry.dat file right now? Have you ever deleted it manually?
Blocks: profile-corrupt
Andrew, 

currently its 116K, I did delete it somewhere around comment #15 is where I did
delete all the profiles/folders and the registry.dat file.  I still have a
problem with this.
FWIW,

this doesn't appear to stem from the localstore.rdf corruption problem, but take
note of bug 90337 comment #58.. and its reference to localstore.rdf corruption,
and then the bug 120049 with RDF:li problem where this started. 

there are several RDF related bugs in bonsai for this time frame: 01/13/2002
00:00 and 01/14/2002 23:59

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=01%2F13%2F02&maxdate=01%2F14%2F02+23%3A59&cvsroot=%2Fcvsroot

bug 113894: RDF persistence breaks when there is a / in the file path.

blob literal support: bug 115926.

Bug 118865, bug 33197. Support serialization of integer and date literals;
support `parseType="Resource"'


This may very well be unrelated, but didn't see anything with build 1-14
timeframe other than this that could be causing this problem.
In the meaning of "the most recently used profile will not 
be highlighted", I'm seeing this on MacOS9 (Japanese).  

Is the bug 120410 another dup of this ?

Sorry.  I mean bug 120598.

*** Bug 120598 has been marked as a duplicate of this bug. ***
yea, same exact problem, but adding that this possible xp toolkit/widget tree
issue, size of outliner window, see dupe for more, also going to say there was a
bug to change to outliner on same bonsai query above.
Its possible, if its trees related & scrollbar issues with a view, Jan may be
able to help figure this out.

so cc'ing Jan on outliner help.
Depends on: 120598
No longer depends on: 120598
*** Bug 120598 has been marked as a duplicate of this bug. ***
*** Bug 128636 has been marked as a duplicate of this bug. ***
renominating for nsbeta1. I think syd thinks this should be fixed, and I 
partially agree (i.e., it is effectively unusable in this state, but, yes, 
you have to have ~7 profiles created before you encounter this bug).
Keywords: nsbeta1- → nsbeta1
nsbeta1- per Nav triage team. So many bugs, so little time; this one is *way*
down the list...
Keywords: nsbeta1 → nsbeta1-
*** Bug 122635 has been marked as a duplicate of this bug. ***
this is *almost* fixed, so now in build 2002-4-10-03 w2k.. thru bug 135048 also
see bug 134889.

The only issue is on creation of the 7th profile, you can click on it, but it
doesn't highlight.  this is only on *creation of it*.. any use afterward of any
profile combinations, this works without a problem.
so this works if you after create the 7th profile, and exit mozilla, then
restart it you can click on it, and the it will highlight.

So Jan, Good work on the outliner fix!

It looks like there needs to be some sort of initialization that needs to be
called as if you just started mozilla from scratch.  

It appears that after creation of a profile, when it updates the view-box
(outliner) there.. it doesn't appear to be executing a refresh/reset/init or
what ever to update the view there like it does upon a fresh mozilla start.

so I bet that is what is left to fix this problem.
I wanna make note before I get too far ahead of myself, is that my testcase in
my dupe is *still valid* for the '8th' profile, I cant get it to highlight at
all unless I use another profile first, then it will.  So It looks like there is
more work to be done here.
*** Bug 147049 has been marked as a duplicate of this bug. ***
As a kind of confirmation of comment #33: with 10 profiles (Netscape and Mozilla
ones) and also with 11 ones it does not work: Most recently used profile will
never look highlighted...
*** Bug 151858 has been marked as a duplicate of this bug. ***
*** Bug 168250 has been marked as a duplicate of this bug. ***
I doubt that 7 is always a magic number.  As I noted in bug #168250, I'm seeing
this problem with fewer than 7 profiles.
I have this problem with 5 profiles.
I think the reason why more dupes are coming in is because the magic number is
now 5 or 6 rather than 7. This has changed because of the addition of the extra
tick box on the profile chooser box making the selection window smaller.

Dupes have been on Mac as well as PC so changing Hardware/OS-> All

Taking out target milestone seeing it's already gone past that, needs to be
re-targetted.
OS: Windows ME → All
Hardware: PC → All
Target Milestone: mozilla1.2alpha → ---
*** Bug 192532 has been marked as a duplicate of this bug. ***
I think the magic number is one. I can't get my only profile highlighted. I have
three 4.x profiles and one Mozilla profile. The 4.x profile names I can
highlight, but not Mozilla's. If it weren't for the fact that on installing each
new build the profile manager is automatically started, I wouldn't know Mozilla
thought there was more than one profile, since that's the only time I ever see
the profile manager. My profiles are in \MOZILLA\PROFILES and \NETSCAPE\Users.

*** Bug 192745 has been marked as a duplicate of this bug. ***
*** Bug 193344 has been marked as a duplicate of this bug. ***
Selection of an previously used item can't be displayed only (see ). And if one
uses mozilla more offen than the others, then only one item seems to be wrong
displayed.
*** Bug 193484 has been marked as a duplicate of this bug. ***
Re Comment #42
In your case the magic number is 4.  The Netscape 4 profiles count.
When it's going to be fixed? The bug is still present in 2003022814 build, but
version 1.3 is being released !!!
The problem here is one of corruption, particularly of registry.dat, which may
go by different names. 

The problem does not occur when profiles are added. The problem only occurs
after at least one profile is deleted, and then others added. Look at the
registry.dat on a computer where Mozilla is exhibiting this problem. I think you
will see several mentions of old, deleted profiles. Once a profile is deleted,
all mention of it should be removed from registry.dat. Currently, it is not. If
we remove all extra data from registry.dat, this problem will go away. That is
because then the registry.dat will be identical to a registry.dat that never
experienced any profile deletions.

That makes this look a lot like bug 113203, which has to do with data loss after
renaming profiles.
Flags: blocking1.4a?
Keywords: testcase
renominating
Keywords: nsbeta1- → nsbeta1
QA Contact: ktrina → gbush
Nav triage team: nsbeta1+/adt3
Assignee: ben → jaggernaut
Status: ASSIGNED → NEW
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt3]
Target Milestone: --- → mozilla1.4beta
*** Bug 197780 has been marked as a duplicate of this bug. ***
I have seen this bug in two separate installations Mozilla 1.3, both running in
Windows 2000.  In both installations, I used the control panel to remove the
previous mozilla installation, and then installed a complete mozilla 1.3 final.
 These installations have about four and five profiles.  Adding a new profile
does not change the behaviour.  This was not observed in the mozilla nightly
build from 2003-01-21. (sorry, build number not readily available).  Suggest
nomination for Mozilla 1.4a.
Flags: blocking1.4a? → blocking1.4a-
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [adt3]
*** Bug 199475 has been marked as a duplicate of this bug. ***
I experienced this problem after my installation of Mozilla 1.3 on windows 2000pro. 
1. I did not uninstall Mozilla 1.2 before installing Mozilla 1.3.
2. I have 6 profiles.
3. When I started up Mozilla 1.3 after the installation was complete the profile
manager would not highlight the profile I had last used the last time I used
Mozilla 1.2 before the installation of 1.3. I could highlight all of the 5 other
profile names.
4. Mozilla 1.3 started up just fine with the (unhighlighted) profile after I
clicked on it.
5. This was fixed after I rebooted and started Mozilla 1.3 again.
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4a) Gecko/20030401]

I also have this bug:
*I have only one Mozilla profile, which I allways use;
 The others profiles are Netscape v4 unmigrated profiles.
 *The Moz profile (created, not migrated) is allways the last one, except for
bug 193753.
*I think this bug has been present for quite some releases !?

This picture is taken after "selecting" (= clicking on") the Mozilla profile.

NB: Going from 24b to 256c reduced the .BMP size from 396KB to 133KB.
Attachment #119744 - Attachment mime type: application/octet-stream → image/bmp
*** Bug 201384 has been marked as a duplicate of this bug. ***
*** Bug 202212 has been marked as a duplicate of this bug. ***
Does this really belong with jag?
[Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.4b) Gecko/20030507]

Bug still there. (with v1.3 profile, at least)


Addition to my comment 57:

I created a 2nd Moz profile, and found that this bug happens in 2 cases:
*always, the last/previous profile used
*immediately after creation, the newly created profile too.

I assume that there might be something messed up in the registry.dat file. Could
somebody please post theirs? While this may seem to disagree with comment 15, it
does not. My guess is that something in our code does something bad and that is
likely to be reflected in the registry.dat file. I don't think the registry.dat
file became corrupt due to external influences, such as from a write that was
incomplete due to a system crash.

Based on comment 4, this looks like a regression that began with the 20020114
builds. Although that comment says "03" for the year, that comment was posted in
the year 2002. Could some intrepid soul track down which check-in caused it?
This file was manually deleted before v1.3 install, and left alone for v1.4a
and v1.4b.
Re comment 62:

I said "immediately after creation, the newly created profile too.".

Well, right now, this is not 100% true.

I think it happened like this tonight:
1. created a profile in v1.4b: no highlight :-(
2. deleted it
3. created a profile in v1.3.1: highlighted :-)
4. deleted it
5. created a profile in v1.4b (to check): highlighted :-)

An unexpected case of auto-repair !?

NB: When I say highlight in this comment, it's light gray, not dark blue :-(
Flags: blocking1.4?
Flags: blocking1.4? → blocking1.4-
*** Bug 209385 has been marked as a duplicate of this bug. ***
This is my recreation scenario with 1.4 nightly build 20030615 on OS/2.  Started
with a fresh build an no profiles:

1) Start mozilla and click "Manage Profiles..." when convert profile dialog
comes up.
2) Create 5 new profiles ("test1", "test2",...,"test5").
3) Start mozilla from profile "test5"
4) Close and restart mozilla

When the Profile Manager appears, you should notice that "test5" is not
highlighted.  If you attempt the same steps with "test4", it will also not be
highlighted when the Profile Manager comes up.  However, this does not happen
for the first three profiles;  they are all properly highlighted.
Enabled Javascript dump() and strict warnings, and I get this error when my
profile doesn't highlight:

JavaScript strict warning:
chrome://global/content/bindings/listbox.xml#listbox.addItemToSelection() line
5: reference to undefined property item.selected
OK, put some dump statements in profileSelection.js, in the functions AddItem()
(which adds the profile names to the profile listbox) and
highlightCurrentProfile().  In highlightCurrentProfile(), I looped over
profileList's childNodes and dumped some info on each one.  Here is what I get:

===  AddItem() - listitem = [object XULElement @ 0x9e3790]
               - listitem.label = pedemont
               - listitem.id = profileName_pedemont
===  AddItem() - listitem = [object XULElement @ 0x9e3bb8]
               - listitem.label = test1
               - listitem.id = profileName_test1
===  AddItem() - listitem = [object XULElement @ 0x9e3f00]
               - listitem.label = test2
               - listitem.id = profileName_test2
===  AddItem() - listitem = [object XULElement @ 0x9f11a8]
               - listitem.label = test3
               - listitem.id = profileName_test3
===  AddItem() - listitem = [object XULElement @ 0x9f13d8]
               - listitem.label = test4
               - listitem.id = profileName_test4
===  AddItem() - listitem = [object XULElement @ 0x9f1480]
               - listitem.label = test5
               - listitem.id = profileName_test5
==> highlightCurrentProfile()
     getting item [profileName_test4] by id
     ======
     These are the labels of the profileList's childNodes:
        item=[object XULElement @ 0x988f70]   id=   label=undefined
        item=[object XULElement @ 0x9e3790]   id=profileName_pedemont  
label=pedemont
        item=[object XULElement @ 0x9e3bb8]   id=profileName_test1   label=test1
        item=[object XULElement @ 0x9e3f00]   id=profileName_test2   label=test2
        item=[object XULElement @ 0x9f11a8]   id=profileName_test3   label=test3
        item=[object XULElement @ 0x9f13d8]   id=profileName_test4   label=undefined
        item=[object XULElement @ 0x9f1480]   id=profileName_test5   label=undefined
     ======
----- currentProfileItem = [object XULElement @ 0x9f13d8]
      currentProfileItem.label = undefined
==> selectItem( [object XULElement @ 0x9f13d8] undefined )
<== selectItem()
<== highlightCurrentProfile()

So for some unknown reason, the label values of 'test4' and 'test5' profiles are
getting corrupted somehow.
OK, added another dump in the AddItem() function: I put a QueryInterface right
after the appendChild call:

  kids.appendChild(listitem);
+ try {
+   dump( "  [] listitem.QI = " +
listitem.QueryInterface(Components.interfaces.nsIDOMXULSelectControlItemElement)
+ "\n" );
+ } catch(e) {
+   dump( "  [] listitem.QI failed !!! \n" );
+ }

And here is the output I got:

=== AddItem()
     listitem= [object XULElement @ 0xa077c8]   id = profileName_pedemont 
label= pedemont
  [] listitem.QI = [object XULElement @ 0xa077c8]
=== AddItem()
     listitem= [object XULElement @ 0xa07c28]   id = profileName_test1  label= test1
  [] listitem.QI = [object XULElement @ 0xa07c28]
=== AddItem()
     listitem= [object XULElement @ 0xa07fa8]   id = profileName_test2  label= test2
  [] listitem.QI = [object XULElement @ 0xa07fa8]
=== AddItem()
     listitem= [object XULElement @ 0xa29288]   id = profileName_test3  label= test3
  [] listitem.QI = [object XULElement @ 0xa29288]
=== AddItem()
     listitem= [object XULElement @ 0xa29480]   id = profileName_test4  label= test4
  [] listitem.QI failed !!! 
=== AddItem()
     listitem= [object XULElement @ 0xa29560]   id = profileName_test5  label= test5
  [] listitem.QI failed !!! 


I have been told that this is probably because the XBL binding is failing on the
last two profiles.  Anyone know XBL innards?
Bryner: can you take a look at this?  Check out the last comment.
*** Bug 211198 has been marked as a duplicate of this bug. ***
Couple of notes:
1. This was happening before the profile manager started using listboxes so will
be something common to both listboxes and trees
2. If you use a buildID 2002011103 or prior then the profile shows up as
selected correctly so even if the registry.dat is corrupted mozilla used to
handle it better.
I'm seeing this on FireBird 20030727 for Linux, and on 0.6.
weird.  i never noticed this until the recent firebird 0.6.1rc builds.

i got it to happen some of the time with the firebird 0.6 milestone, and most of
the time with the 0.6.1rc builds all on windows 2000.  usually the first few
profiles would work, but profiles farther down the list wouldn't be highlighted.

interestingly, i have a custom theme that i replace classic.jar with.  it loads
up front, and skins the profile manager.  and i never get the non-highlighted
thing with it.  no matter which profile was last used, or how many profiles
there are.  so this might be semi-theme related.  i'm trying sift thru the css
and find out what might cause it.
The problem is still present in resent builds with file in attachment
http://bugzilla.mozilla.org/attachment.cgi?id=126810&action=view. The last item
cann't be highlighted, after it has been selected last time.
*** Bug 217589 has been marked as a duplicate of this bug. ***
*** Bug 219732 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030

Interesting:  I recently upgraded from Win2K to WinXP (fresh install, actually,
not an upgrade.  I blew away the entire Mozilla install directory), and kept my
profile directory in tact.  I did have to re-add all of the profiles (i.e.
mainly just to point Mozilla to the proper directory locations of the
pre-existing profiles), and now the highlighting works properly.

Could this be a case where there is some corrupt information stored in the
Mozilla configuration registry?  Since the profile directories themselves
weren't modified in any way, it would have to be something outside that space.
*** Bug 231672 has been marked as a duplicate of this bug. ***
Unsetting missed milestone target.
Flags: blocking1.7a?
Target Milestone: mozilla1.4beta → ---
Probably not going to hold the release for this since it's really a visual
glitch and not a loss of functionality. Neil, can you help us with this?
Flags: blocking1.7a? → blocking1.7a-
Sorry, it's not sufficiently reproducible for me to help.
If I see it happen, then I'll try to remember to look into it.
Neil, I have it fully reproducable, so just grab me when you see me on #mozilla
and I'll get you any information you need that I can get.
OK, with some help from Ian, the problem only occurs if the current profile is
not on the first screenful of profiles.
I'm seeing a recursive call to the non-reentrant EnsureIndexIsVisible :-(
Attached patch Proposed patch (obsolete) — — Splinter Review 
OK, so this fixes it by removing the reentrancy - I also tried removing
profiles one by one until the scrollbar disappears and indeed once it does so
row 0 becomes visible even without that code.
Assignee: jag → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Whoops, wrong patch :-[
Attachment #141058 - Attachment is obsolete: true
Attachment #141060 - Flags: superreview?(bzbarsky)
Attachment #141060 - Flags: review?(roc)
Comment on attachment 141058 [details] [diff] [review]
Proposed patch

add a comment why you commented out that piece of code. Bug number should be
sufficient :)
let's hope it's not going to break anything
r=varga
Attachment #141058 - Flags: review+
(In reply to comment #86)
> OK, with some help from Ian, the problem only occurs if the current profile is
> not on the first screenful of profiles.

not quite.  i'm still getting it with firebird builds from 0.6.1 to recent.  it
can happen to the last profile on a list of 4, which are all visible - no
scrollbar.  it also occurs on any additional profiles after the 4th.  it does
not happen to profiles 1-3.  contrary to my previous experience with this bug
(comment #76), this sounds a little more in line with other comments.  if you
ask me, the circumstances which cause it are still a bit unpredictable (i.e. the
"magic number").  so i'm not sure if this patch will truly fix it (comment #49,
comment #63, comment #69, comment #74)

not sure if it means anything, but lately i always get this js error in the
0.6.1 build:
Error: uncaught exception: [Exception... "Component returned failure code:
0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getBoolPref]"  nsresult:
"0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame ::
chrome://communicator/content/profile/profileSelection.js :: StartUp :: line 97"
 data: no]

no errors in the other builds on windows 2000.
I applied patch 141060 to my debug tree and recompiled /layout. I then deleted
compreg.dat and chrome.rdf/overlayinfo. I started |mozilla -p| to bring up the
profile selection: still no selection in the listbox! :(

Furthermore, it's getting worse: with this patch applied, the first entry of
listbox is plain white (even though mouse-selecting it shows brings up its
name). The formerly invisibly selected profile entry does now get a focus frame
border, but no focus bakground - and I can't start that profile anymore. :(

I don't think that the scrollbar behaviour is relevant in this bug - I have only
four profiles and can see the bug nonetheless:
- start with |mozilla -p "kddev"|
- shutdown mozilla
- start with |mozilla -p|
- "kddev" is invisibly selected (as one finds out by keyboard-moving the
selection), but usable.

After some hacking I found out that the "manifestation line" of this bug is
      profileList.selectItem( currentProfileItem );
in highlightCurrentProfile() in
http://lxr.mozilla.org/seamonkey/source/profile/resources/content/profileSelection.js#118

|selectItem| is a method of the "listbox" binding in listbox.xml and in turn
calls another method named |addItemToSelection|. This function tries to execute
          item.selected = true;
on the listitem to be selected - and fails. The "listitem" binding has *not* yet
been attached to the listitem and hence the setter for property |selected| in
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/bindings/listbox.xml#759
can't be executed...
If you can reproduce this with the Switch Profile dialog (those of you that have
it), can you open the DOM Inspector, open the Switch Profile dialog, inspect the
broken item, look in Computed Style and XBL Bindings and see that the binding
isn't actually there? In Ian's case, DOM Inspector said that the binding was
there, but because of the reentrancy bug it hadn't actually been attached correctly.
DOMI says (in XBL and Computed Style) that the listitem has the binding
"listitem-iconic" (and that's extending the binding "listitem"). DOMI shows the
|selected| property's getter and setter. 
DOMI also shows an object member |selected| attached to the listitem object that
seems to shadow the binding's |selected| property. After evaluating the JS
commands |delete target.selected| and |target.selected=true|, the listitem is
correctly highlighted.
(I remember having had a very similar problem during 1.3 or something, but don't
ask me for details. :( )
That version of the problem sounds suspiciously similar to bug 90337, which ere
claims to have fixed...
Comment on attachment 119744 [details]
Screen Capture of non-highlighted profile


[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113] (W98SE)

(for the record)
Now (v1.6), the Mozilla profile appears at the top/before of the NetscapeV4
ones...
Comment on attachment 141060 [details] [diff] [review]
Proposed patch
[Checked in: Comment 100]

sr=bzbarsky if this is really no longer needed.
Attachment #141060 - Flags: superreview?(bzbarsky) → superreview+
Comment on attachment 141060 [details] [diff] [review]
Proposed patch
[Checked in: Comment 100]

Yeah, the nsGfxScrollFrame should scroll us up to the top if it removes the
vertical scrollbar.
Attachment #141060 - Flags: review?(roc) → review+
Comment on attachment 141060 [details] [diff] [review]
Proposed patch
[Checked in: Comment 100]

Asa, if you still want this...
Attachment #141060 - Flags: approval1.7a?
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Attachment #141060 - Attachment description: Proposed patch → Proposed patch [Checked in: Comment 100]
Neil: I'm not sure why this bug is marked fixed. 
As far as I can see the patch does not seem to have improved the problem
described by this bug. And maybe even introduced another problem (the empty
line, see comment #92, I also saw it once in profile manager, and always in
"switch profile").
Comment on attachment 141060 [details] [diff] [review]
Proposed patch
[Checked in: Comment 100]

didn't make the alpha train.
Attachment #141060 - Flags: approval1.7a?
Reopening as bug is not fixed, screenshots to follow.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is from BuildID 2004022315 (though downloaded 2004022410) running on WinXP
SP1
Screenshot containing 4 Select User Profile dialog boxes A through to D
A, B and C show the list of users, Default User is the one that should be
highlighted. Dialog A is how it first opens, B is when you scroll to the top, C
is when you scroll to the bottom (not sure if the blank at the bottom is
significant).
Dialog D comes from selecting Tools, Switch Profile - note how the top user
"evansp" is completely missing.
Interesting... the previous bug was caused by the scroll bar, this version is
caused by the lack of the scroll bar...
Status: REOPENED → ASSIGNED
Neil, this checkin broke the filter and search dialogs in mail. See Bug #235451
for more details...Thanks!
Perhaps the list used the scrollbar event to construct the list item frames?
Blocks: 235451
No longer blocks: 235451
Blocks: 235451
uhh...  i don't think we're all on the same page here.

(In reply to comment #106)
> Interesting... the previous bug was caused by the scroll bar, this version is
> caused by the lack of the scroll bar...

the original issue as reported (last used profile appears unhighlighted on next
run) is NOT affected by the scroll bar/lack thereof.  i've seen this bug on ~0.6
firebird builds all the way up to post-0.8 firefox nightlies.  i get it
regardless of whether there's a scrollbar.

with recent firefox nightlies i also see the NEW issue reported in comment #105,
and that is almost certainly something different, which probably needs its own
bug.  for me, it occurs with the launch-time profile manager (no switcher in the
fox) WITH a scrollbar.
- i have five profiles in the list. the list can show ~4.8 items at once.
- the last-used profile is at the bottom causing the list to be scrolled down
from the start.
- the item at the top of the visible list (second actual item) is not drawn, and
cannot be directly selected by clicking.
  - however, selecting a profile below it, and arrowing up causes it to be drawn
and selected.
- clicking the up scrollbar button causes it to be drawn, but does not scroll
the list.
  - clicking a second time scrolls the list.
- scrolling with the thumb, clicking in the bar above the thumb, the mousewheel,
and the Page Up key cause the items to be drawn and the list to scroll up.

for some reason, it doesn't occur when a profile higher up on the list is
last-used, even if the list is scrolled to the bottom from the start.

> (not sure if the blank at the bottom is significant)

as for the "blank at the bottom" - that is just a theme issue - the listbox's
fixed size doesn't allow x items evenly.  notice the longer list in the switch
dialog due to the lack of the "Work Offline" checkbox.  you might see the same
thing in the theme/extension lists.  probably not a factor.

hmm.  and now i seem to have lost a profile.  probably from running firebird and
firefox at the same time.  but that is neither here or there.
OK, so it looks like the ian's missing row issue and mscott's missing row issue
are completely separate problems. ian's problem is that the list wasn't
properly scrolling when its size changed. mscott's problem is that before a
list's size is known it doesn't know how to scroll properly; this problem was
hidden before because the listbox blindly scrolled to the top anyway, which is
what hurt the profile manager in the first place.
Attachment #142231 - Flags: superreview?(mscott)
Attachment #142231 - Flags: review?(varga)
Attachment #142231 - Flags: review?(varga) → review+
Attachment #142231 - Flags: superreview?(mscott) → superreview+
The new problem has gone away with the supplemental patch, but the original
problem is still there.
Okay, been digging a bit further.
1. On a system which has 5 Netscape 4.x profiles and no mozilla profiles setup
(deleted mozilla folder in c:\documents and settings\administrator\application data)
2. Start Mozilla buildID 2004030108
3. No profile highlighted though you can highlight any of them (probably another
bug)
4. Select top profile in list to convert
5. Check highlights via tools, switch profile
6. Restart mozilla using -profilemanager switch
7. Correct profile is highlighted

Alternatively:
Steps 1-3 as above
4. Select bottom (5th profile) in list to convert
5. Highlight doesn't work if you try via tools, switch profile
6. Restart mozilla using -profilemanager switch
7. Profile does not highlight.
Attached file testcase — 
Attaching a testcase. Open it using -chrome file:///path/profile.xul.
The profile 'testuser' should be selected, but isn't. If you manually select
another profile, it's ok. But after that, if you select testuser again, it has
a focus ring, but no background color.
(In reply to comment #113)
> Created an attachment (id=142753)
> testcase

WFM?  'testuser' is preselected for me in firebird 0.6.1 with a custom theme,
and in firefox 20040229 default theme.
with lists and trees there are 2 possible states: selected and current. 
'selected' is when it is shaded or highlighted; and sometimes more than one item
can be selected at once (bookmarks manager).  'current' gives the border (focus
ring) to the last item clicked.
for me, 'testuser' is preselected, but not current - highlighted, but no border.
 clicking on other items will select/current them, but then 'testuser' stays
selected as well.  selecting another item then arrowing towards 'testuser'
causes weird things.  from above, it hits 'testuser' then jumps back to the top.
 from the bottom, it hits 'testuser' and stops.

everytime i click on an item i get a couple of these js errors:
Error: [Exception... "'Permission denied to get property UnnamedClass.classes'
when calling method: [nsIAccessibleProvider::accessible]"  nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]
Did you open it using -chrome file:///path/profile.xul ?
If i just open it in the browser, it indeed works. If i use it as chrome (like
the real profile manager is), it doesn't work.

To update the testcase to what the current code is, change this:
-         currentProfileItem.selected = true;
+         profileList.selectItem( currentProfileItem );
+         profileList.ensureElementIsVisible( currentProfileItem );

indeed, it isn't highlighted.  apologies for my previous comment - i wasn't
aware there was a difference between -chrome and just opening it.  the arrowing
weirdness is the same.  and with my custom theme i can directly click on
'testuser' and get a focus ring, but no highlight. in my theme i define separate
selected and current states.  in the default theme there is only a selected
state and a combined selected+current state.

i should also clarify - the item *is* actually selected (in the profile manager,
you can hit enter, and that profile will load), it only *appears* not selected.
inspect the test case in DOMI, and you'll see all the listitems have the same
dom nodes - 'testuser' does not have selected="true".  the javascript object
correctly shows selected="true".
(In reply to comment #115)
>+         profileList.selectItem( currentProfileItem );
>+         profileList.ensureElementIsVisible( currentProfileItem );
These lines, also available at lines 47 and 48 or profileManager.js, trigger the
latest reproducible issue. For some reason the selectItem call is happening
after the xbl is bound to the listitem (that has already been added to the
document) but if you switch those two lines then everything is hunky-dory. Now I
know that if you have an object with a frame then it will get an XBL binding; if
it's never had a JS wrapper then one will be created when it's first accessed,
but this appears to be a loophole - the element is added to the document but
doesn't get an XBL binding because it has no frame.
Attached file testcase — 
This testcase will run in the browser. All the buttons in the second row should
be disabled.
What fun.

Here's what's going on:

1) You create an element.  It has no document, so the wrapper we create for it
   doesn't load the XBL binding (fogetting for now that it makes no sense to
   apply  an XBL binding to a node that's not in a document...)
2) You insert the node into the document as a child of a display:none element.
   That means we never even try to construct a frame for it, so the binding is
   not attached.
3) You try to set a property that's implemented by the binding.  No binding, so
   this just sets the property on the JSObject, not the attribute on the DOM
   node.

and then it's all downhill from there.

Now I would think that we _would_ load the binding in step 2.  That should
probably be done by nsContentUtils::ReparentContentWrapper.  But of course this
is a XUL element, and XUL elements don't even get their content wrappers
reparented (see bug 235640).  So that probably needs to be fixed first, followed
by fixing ReparentContentWrapper.

Alternately, we need a better solution to force loading of bindings for a
node... The current hacks to make bindings attach to nodes that are not in
documents, the hack when creating a content wrapper, etc, are pretty uncalled for.
Depends on: 235640
I've tried switching lines 47 and 48 round in profileManager.js and it does not
provide a workaround, the same behaviour as before is exhibited.
I also did switches on lines 197 and 198 in profileManager.js and 118 and 119 in
profileSelection.js and this didn't fix my startup problem detailed in commment#112
Attached patch Switches (obsolete) — — Splinter Review 
Strange, because when I made these switches the problem went away...
We should probably file a separate bug on loading bindings when we reparent
content wrappers (per comment 119).  This one has far too much noise to be used
for that, and may end up with a fix in the JS anyway.
I've added the extra change:
-  var profile = new Profile( aProfName, aProfDir, "yes" );
+  var profile = new Profile( aProfName, "yes" );
and it still has made no difference.
I start with 5 non-migrated NS 4.x profiles and select the 5th one in the list,
when I restart mozilla with the -profilemanager command the 5th profile is
selected but not highlighted.
Dear Ladies and Gentlemen,

we recently discovered the same error in Mozilla as is described in this bug.

Operating System: Windows 2000
Mozilla 1.6 (Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.6) Gecko/20040113

Mozilla is used with different profiles for different email accounts. Initially,
when profile A is selected, the profile is highlighted in the profile manager as
it should be. Then, after exiting and restarting mozilla, profile A isn&#8217;t
highlighted but can be correctly started. The other profiles are highlighted
correctly. Then, when one starts mozilla with profile B, after exiting and
restarting, profile B isn&#8217;t highlighted any more (but can still be started), and
profile A is correctly highlighted again. So, this indeed seems to be the same
bug as mentioned in this bug report.

Our question regarding this bug is, is this already fixed or will it be fixed in
the near future? Or is there a workaround for this bug?

For answers to this or any additional questions, please respond to the email
address mentioned below.


Yours sincerely

Weiß Software & Systeme GmbH
Sven Schuster
Email address: sven.schuster@weiss-software.de

Still having the issue on w2k build 2004041310 (1.7b)

Only happens on the last Mozilla (native) profile which is above my other NS4.7x
profiles 

I have 4 different profiles of each type (native and NS4.7 - these raenot used
any more actually)

I have this behavior since 1.1,  I believe.
I used to suspect a buggy Matrox video driver, but I switched to a recent ati
and still have the same issue.

*** Bug 241706 has been marked as a duplicate of this bug. ***
QA Contact: agracebush → benc
Attached patch New approach (obsolete) — — Splinter Review 
Ok, so I was able to reproduce the issue even with attachment 143022 [details] [diff] [review]; hopefully
moving the selection logic into AddItem will kill this one once and for all.
Attachment #143022 - Attachment is obsolete: true
Bad news I'm afraid, tested with patch applied and steps from comment 124 still
cause the bug to show :-(
Selecting the current profile after a timeout does appear to be more reliable.
I haven't been able to figure out why yet, but the profile isn't quite scrolled
into view, so as a double hack I set a second timeout to ensure it's visible.
Attachment #148509 - Attachment is obsolete: true
Latest patch does seem to fix the problem.
Comment on attachment 149308 [details] [diff] [review]
Possible branch band-aid

This is only intended to be a bit of branch band-aid so that the problem does
not appear. For the trunk I have decided to convert the list into a tree
instead.
Attachment #149308 - Attachment description: Lame hack → Possible branch band-aid
Attachment #149308 - Flags: superreview?(alecf)
Attachment #149308 - Flags: review?(varga)
Comment on attachment 149308 [details] [diff] [review]
Possible branch band-aid

heh yeah that's a band-aid all right :)
sr=alecf
Attachment #149308 - Flags: superreview?(alecf) → superreview+
Attachment #149308 - Flags: review?(varga) → review+
Comment on attachment 149308 [details] [diff] [review]
Possible branch band-aid

Low-risk band-aid fix for branch.
Attachment #149308 - Flags: approval1.7?
Comment on attachment 149308 [details] [diff] [review]
Possible branch band-aid

a=chofmann for 1.7
Attachment #149308 - Flags: approval1.7? → approval1.7+
Fix checked into the 1.7 branch.
Keywords: fixed1.7
(1.7 branch) VERIFIED: 06-01, Mac OS X 10.3.3
The problem was in 1.7RC2, but gone from my newer build.
I'll try to verify windows soon.
Keywords: fixed1.7, nsbeta1- → verified1.7
Whiteboard: checkwinbranch, checklinuxbranch
WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040601
Whiteboard: checkwinbranch, checklinuxbranch → , checklinuxbranch
Attachment #149915 - Flags: review?(varga)
Comment on attachment 149915 [details] [diff] [review]
Convert the trouble listbox to a friendly tree

r=varga
Attachment #149915 - Flags: review?(varga) → review+
Attachment #149915 - Flags: superreview?(jag)
I am not quite sure is this the same bug, but it is closely related.
This is a user interface problem, whitch I managed to overcom by selecting
first an other Profile, that could be opened. Then by selecting
Switch Profile, I could select any of the profiles, BUT,
it caused the browser to think, that it was in offline mode.
So I had to check the offline away and then be back online
with the favorite profile.
This happened to me, when I had the profiles on a FAT32 filesystem,
and using the same profiles for both when I booted Windows or Linux.
My original problem, with the password manager, that could no more 
reveal the encrypted password, still exists.

Mikko Silvennoinen
Even if this fixes the problem in the profile dialog, it seems like theres'
still a but in the list code, no? If so, please make sure there's a bug on file
on that if this code is closed after it no longer uses the list code.
(In reply to comment #143)
>Even if this fixes the problem in the profile dialog, it seems like there's
>still a bug in the list code, no?
It might be a list bug, a CSS bug, or an XBL bug: XBL gets bound when either
a) an element's frame gets created
b) an elements JS wrapper gets created
However in case b) if the element is not in a document at the time (i.e. it was
created by JS) it has no style to tell it that it will have an XBL binding.
Furthermore listbox child frames get created asynchronously for performance
reasons, and then only for visible rows, so case a) does not apply either.
This probably just needs a slight tweak but if you go into tools and switch
profile under classic theme, the profile names are too close to the icons in
the dialog box that comes up.

This is using Build ID 2004060809 on Win XP SP1 with patch in attachment 149915 [details] [diff] [review]
applied.
WFM on Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7) Gecko/20040606
update of the bug status ?
Oliver: this was branch fixed, so yeah, the trunk status is still assigned.

Mikko: I've had some recent complaints about profiles starting offline, but that
really needs to be in it's own bug. 
effectivelly NOT IN 1.8 build 2004061507
please keep in mind !
not yet in build 2004070108
Flags: blocking1.8a2+
olivier.vit:
Are you member of the drivers group?
If not, please reset the flag you just set, or set it to end in a question mark
to *request* blocker status!
Only drivers may confirm blocker status! Don't use functionality you don't know!
my intention was question mark, sorry, sorry, sorry !
Flags: blocking1.8a2+ → blocking1.8a2?

        Attachment #149915 -
        Attachment is obsolete: true

    
  

        Attachment #152204 -
        Flags: superreview?(jag)

        Attachment #152204 -
        Flags: review?(varga)

        Attachment #149915 -
        Flags: superreview?(jag)

    
    

    
  
Comment on attachment 152204 [details] [diff] [review]
Pad out the image

sr=jag

        Attachment #152204 -
        Flags: superreview?(jag) → superreview+

    
    

    
  
Comment on attachment 152204 [details] [diff] [review]
Pad out the image

Looks good
r=varga

        Attachment #152204 -
        Flags: review?(varga) → review+

    
    

    
  
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED

    
  
Flags: blocking1.8a2?

    
    

    
  
Comment on attachment 152204 [details] [diff] [review]
Pad out the image

>-  if( aEvent.detail == 2 && aEvent.button == 0 && aEvent.target.localName == "listitem") {
>+  if (aEvent.button == 0 && event.target.parentNode.view.selection.count) {
			      ^^^^^ Should be "aEvent"
This will break click action.

    
    

    
  
Typo fix checked in. Thanks for spotting it!
Product: Browser → Seamonkey

    
    

    
  


The browser ask about choosing a profile because one is in use, and I lost my
bookmarked sites when tried to reach my profile wich was the default. I saw two
and renamed the one I was using but  the browser didn't let me use it. It said
that that profile was in use that I had to choose another one.

    
    

    
  
V/fixed, 1.7.8 linux (finally).

I'm upgrading a lot of my systems, I'll see if I can trunk verify.
Whiteboard: , checklinuxbranch

    
    

    
  
this is not fixed. using nightly builds I'm still experienceing this problem. I
have 3 profiles and I cant select the theird one. doing so selects nothing.
pressing run firefox correctly starts firefox with the "unselected" profile.

    
    

    
  
(In reply to comment #160)
>pressing run firefox correctly starts firefox with the "unselected" profile.
Except this bug is for Suite, not Firefox...
Depends on: 413336

    
  
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.