120410 - Select a profile name and it is not highlighted

Status: VERIFIED FIXED

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

Description

[Ninoschka Baca]

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.

Comment 1

[Ninoschka Baca]

Marking nsbeta1 because this is confusing.

Comment 2

[Asa Dotzler [:asa]]

bug 120063?

Comment 3

[[not reading bugmail]]

*** Bug 120063 has been marked as a duplicate of this bug. ***

Comment 4

[[not reading bugmail]]

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.

Comment 5

[[not reading bugmail]]

its also an issue in 1-17-03 w2k build.

Comment 6

[Antonio Lam]

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.

Comment 7

[[not reading bugmail]]

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.

Comment 8

[Ninoschka Baca]

Grace, how many profiles existed before you also saw this problem?

Comment 9

[[not reading bugmail]]

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.

Comment 10

[[not reading bugmail]]

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.

Comment 11

[[not reading bugmail]]

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.

Comment 12

[[not reading bugmail]]

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?

Comment 13

[[not reading bugmail]]

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.

Comment 14

[[not reading bugmail]]

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?

Comment 15

[[not reading bugmail]]

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.

Comment 16

[Grace Bush]

*** Bug 124779 has been marked as a duplicate of this bug. ***

Comment 17

[Peter Trudelle]

nsbeta1- per ADT triage team

Comment 18

[Andrew Hagen]

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?

Comment 19

[[not reading bugmail]]

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.

Comment 20

[[not reading bugmail]]

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.

Comment 21

[chado]

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 ?

Comment 22

[chado]

Sorry.  I mean bug 120598.

Comment 23

[[not reading bugmail]]

*** Bug 120598 has been marked as a duplicate of this bug. ***

Comment 24

[[not reading bugmail]]

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.

Comment 25

[[not reading bugmail]]

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.

Comment 26

[John Morrison]

*** Bug 120598 has been marked as a duplicate of this bug. ***

Comment 27

[John Morrison]

*** Bug 128636 has been marked as a duplicate of this bug. ***

Comment 28

[John Morrison]

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).

Comment 29

[Peter Trudelle]

nsbeta1- per Nav triage team. So many bugs, so little time; this one is *way*
down the list...

Comment 30

[K'Trina Medina]

*** Bug 122635 has been marked as a duplicate of this bug. ***

Comment 31

[[not reading bugmail]]

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.

Comment 32

[[not reading bugmail]]

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.

Comment 33

[[not reading bugmail]]

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.

Comment 34

[Grace Bush]

*** Bug 147049 has been marked as a duplicate of this bug. ***

Comment 35

[Andreas Kunz]

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...

Comment 36

[Grace Bush]

*** Bug 151858 has been marked as a duplicate of this bug. ***

Comment 37

[R.K.Aa.]

*** Bug 168250 has been marked as a duplicate of this bug. ***

Comment 38

[Ray Charbonneau]

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.

Comment 39

[edmz]

I have this problem with 5 profiles.

Comment 40

[Ian Neal]

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.

Comment 41

[Grace Bush]

*** Bug 192532 has been marked as a duplicate of this bug. ***

Comment 42

[Felix Miata]

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.

Comment 43

[Grace Bush]

*** Bug 192745 has been marked as a duplicate of this bug. ***

Comment 44

[Grace Bush]

*** Bug 193344 has been marked as a duplicate of this bug. ***

Comment 45

[Arkady Sherman]

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.

Comment 46

[R.K.Aa.]

*** Bug 193484 has been marked as a duplicate of this bug. ***

Comment 47

[Ray Charbonneau]

Re Comment #42
In your case the magic number is 4.  The Netscape 4 profiles count.

Comment 48

[Arkady Sherman]

When it's going to be fixed? The bug is still present in 2003022814 build, but
version 1.3 is being released !!!

Comment 49

[Andrew Hagen]

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.

Comment 50

[Grace Bush]

renominating

Comment 51

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 52

[Torben]

*** Bug 197780 has been marked as a duplicate of this bug. ***

Comment 53

[John Scogin]

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.

Comment 54

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 55

[Grace Bush]

*** Bug 199475 has been marked as a duplicate of this bug. ***

Comment 56

[jdecaro]

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.

Comment 57

[Serge Gautherie (:sgautherie)]

[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 !?

Comment 58

[Serge Gautherie (:sgautherie)]

Attachment: Screen Capture of non-highlighted profile

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.

Comment 59

[Grace Bush]

*** Bug 201384 has been marked as a duplicate of this bug. ***

Comment 60

[Felix Miata]

*** Bug 202212 has been marked as a duplicate of this bug. ***

Comment 61

[Mike Kaply [:mkaply]]

Does this really belong with jag?

Comment 62

[Serge Gautherie (:sgautherie)]

[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.

Comment 63

[Andrew Hagen]

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?

Comment 64

[Serge Gautherie (:sgautherie)]

Attachment: registry.dat (after comment 62), requested by comment 63

This file was manually deleted before v1.3 install, and left alone for v1.4a
and v1.4b.

Comment 65

[Serge Gautherie (:sgautherie)]

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 :-(

Comment 66

[Grace Bush]

*** Bug 209385 has been marked as a duplicate of this bug. ***

Comment 67

[jhp (no longer active)]

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.

Comment 68

[jhp (no longer active)]

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

Comment 69

[jhp (no longer active)]

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.

Comment 70

[jhp (no longer active)]

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?

Comment 71

[jhp (no longer active)]

Bryner: can you take a look at this?  Check out the last comment.

Comment 72

[Felix Miata]

*** Bug 211198 has been marked as a duplicate of this bug. ***

Comment 73

[Arkady Sherman]

Attachment: The file with the problem

Comment 74

[Ian Neal]

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.

Comment 75

[Scott Gifford]

I'm seeing this on FireBird 20030727 for Linux, and on 0.6.

Comment 76

[miahz]

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.

Comment 77

[Arkady Sherman]

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.

Comment 78

[Bill Mason]

*** Bug 217589 has been marked as a duplicate of this bug. ***

Comment 79

[Grace Bush]

*** Bug 219732 has been marked as a duplicate of this bug. ***

Comment 80

[Thomas Brown]

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.

Comment 81

[Felix Miata]

*** Bug 231672 has been marked as a duplicate of this bug. ***

Comment 82

[Felix Miata]

Unsetting missed milestone target.

Comment 83

[Asa Dotzler [:asa]]

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?

Comment 84

[[e-mail]]

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.

Comment 85

[Ian Neal]

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.

Comment 86

[[e-mail]]

OK, with some help from Ian, the problem only occurs if the current profile is
not on the first screenful of profiles.

Comment 87

[[e-mail]]

I'm seeing a recursive call to the non-reentrant EnsureIndexIsVisible :-(

Comment 88

[[e-mail]]

Attachment: Proposed patch

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.

Comment 89

[[e-mail]]

Attachment: Proposed patch [Checked in: Comment 100]

Whoops, wrong patch :-[

Comment 90

[Jan Varga [:janv]]

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

Comment 91

[miahz]

(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.

Comment 92

[Karsten Düsterloh]

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...

Comment 93

[[e-mail]]

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.

Comment 94

[Karsten Düsterloh]

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. :( )

Comment 95

[[e-mail]]

That version of the problem sounds suspiciously similar to bug 90337, which ere
claims to have fixed...

Comment 96

[Serge Gautherie (:sgautherie)]

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 97

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141060 [details] [diff] [review]
Proposed patch
[Checked in: Comment 100]

sr=bzbarsky if this is really no longer needed.

Comment 98

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 99

[[e-mail]]

Comment on attachment 141060 [details] [diff] [review]
Proposed patch
[Checked in: Comment 100]

Asa, if you still want this...

Comment 100

[[e-mail]]

Fix checked in.

Comment 101

[Andreas Kunz]

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 102

[Asa Dotzler [:asa]]

Comment on attachment 141060 [details] [diff] [review]
Proposed patch
[Checked in: Comment 100]

didn't make the alpha train.

Comment 103

[Ian Neal]

Reopening as bug is not fixed, screenshots to follow.

Comment 104

[Ian Neal]

Attachment: Screenshot of non-highlighted profile (original problem)

This is from BuildID 2004022315 (though downloaded 2004022410) running on WinXP
SP1

Comment 105

[Ian Neal]

Attachment: 4 Screenshots showing new problem

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.

Comment 106

[[e-mail]]

Interesting... the previous bug was caused by the scroll bar, this version is
caused by the lack of the scroll bar...

Comment 107

[Scott MacGregor]

Neil, this checkin broke the filter and search dialogs in mail. See Bug #235451
for more details...Thanks!

Comment 108

[[e-mail]]

Perhaps the list used the scrollbar event to construct the list item frames?

Comment 109

[miahz]

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.

Comment 110

[[e-mail]]

Attachment: Supplemental patch

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.

Comment 111

[Ian Neal]

The new problem has gone away with the supplemental patch, but the original
problem is still there.

Comment 112

[Ian Neal]

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.

Comment 113

[Michiel van Leeuwen (email: mvl+moz@)]

Attachment: 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.

Comment 114

[miahz]

(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]

Comment 115

[Michiel van Leeuwen (email: mvl+moz@)]

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 );

Comment 116

[miahz]

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".

Comment 117

[[e-mail]]

(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.

Comment 118

[[e-mail]]

Attachment: testcase

This testcase will run in the browser. All the buttons in the second row should
be disabled.

Comment 119

[Boris Zbarsky [:bzbarsky]]

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.

Comment 120

[Ian Neal]

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.

Comment 121

[Ian Neal]

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

Comment 122

[[e-mail]]

Attachment: Switches

Strange, because when I made these switches the problem went away...

Comment 123

[Boris Zbarsky [:bzbarsky]]

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.

Comment 124

[Ian Neal]

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.

Comment 125

[Sven Schuster]

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’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’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: [e-mail]

Comment 126

[Olivier Vit (just a reporter)]

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.

Comment 127

[Felix Miata]

*** Bug 241706 has been marked as a duplicate of this bug. ***

Comment 128

[[e-mail]]

Attachment: New approach

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.

Comment 129

[Ian Neal]

Bad news I'm afraid, tested with patch applied and steps from comment 124 still
cause the bug to show :-(

Comment 130

[Ian Neal]

Attachment: registry.dat which shows problem

Comment 131

[[e-mail]]

Attachment: Possible branch band-aid

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.

Comment 132

[Ian Neal]

Latest patch does seem to fix the problem.

Comment 133

[[e-mail]]

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.

Comment 134

[Alec Flett]

Comment on attachment 149308 [details] [diff] [review]
Possible branch band-aid

heh yeah that's a band-aid all right :)
sr=alecf

Comment 135

[[e-mail]]

Comment on attachment 149308 [details] [diff] [review]
Possible branch band-aid

Low-risk band-aid fix for branch.

Comment 136

[chris hofmann]

Comment on attachment 149308 [details] [diff] [review]
Possible branch band-aid

a=chofmann for 1.7

Comment 137

[[e-mail]]

Fix checked into the 1.7 branch.

Comment 138

[benc]

(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.

Comment 139

[Arkady Sherman]

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040601

Comment 140

[[e-mail]]

Attachment: Convert the trouble listbox to a friendly tree

Comment 141

[Jan Varga [:janv]]

Comment on attachment 149915 [details] [diff] [review]
Convert the trouble listbox to a friendly tree

r=varga

Comment 142

[Mikko Silvennoinen]

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

Comment 143

[Johnny Stenback (:jst)]

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.

Comment 144

[[e-mail]]

(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.

Comment 145

[Ian Neal]

Attachment: Icons to close to profile names in classic theme

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.

Comment 146

[Olivier Vit (just a reporter)]

WFM on Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7) Gecko/20040606
update of the bug status ?

Comment 147

[benc]

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. 

Comment 148

[Olivier Vit (just a reporter)]

effectivelly NOT IN 1.8 build 2004061507
please keep in mind !

Comment 149

[Olivier Vit (just a reporter)]

not yet in build 2004070108

Comment 150

[Andreas Kunz]

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!

Comment 151

[Olivier Vit (just a reporter)]

my intention was question mark, sorry, sorry, sorry !

Comment 152

[[e-mail]]

Attachment: Pad out the image

Comment 153

[jag (Peter Annema)]

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

sr=jag

Comment 154

[Jan Varga [:janv]]

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

Looks good
r=varga

Comment 155

[[e-mail]]

Fix checked in.

Comment 156

[Pete Zha]

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.

Comment 157

[[e-mail]]

Typo fix checked in. Thanks for spotting it!

Comment 158

[Dilsia A. Martinez]

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.

Comment 159

[benc]

V/fixed, 1.7.8 linux (finally).

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

Comment 160

[Henrik Gemal]

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.

Comment 161

[[e-mail]]

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