279497 - Selected profile in profile manager does not always appear focused/highlighted

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[djpohly]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050123 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050123 Firefox/1.0+

In the Profile Manager listbox, some profiles will not appear focused when they
actually are.

Reproducible: Always

Steps to Reproduce:
1. Open Profile Manager with firefox -p or via MOZ_NO_REMOTE.
2. Ensure that there are several profiles to choose from.  Add some if needed.
3. Click to select each profile.

Actual Results:  
Some profiles will not appear to be selected (no focus rectangle or highlight).

Expected Results:  
Highlight the clicked profile.

Regressed between nightly builds 2005-01-19 and 2005-01-20.

Comment 1

[Ben Fowler]

I saw this on yesterday's Mac OS X Firefox.

Comment 2

[Kevin Brosnan]

I only see this once a new profile is created using a current nighly build. I do
not see this on Mozilla trunk builds.

Comment 3

[Benjamin Smedberg]

profile manager is not exposed UI, not a blocker.

Comment 4

[djpohly]

I don't have to create a new profile to reproduce this; rather it seems that
whichever profile is set Default=1 in profiles.ini will exhibit this behavior.

Comment 5

[Fred Collier]

Concur with Devin.  Only default profile (from profile.ini) shows this behavior.

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b) Gecko/20050124 Firefox/1.0+

Comment 6

[Joe Llywelyn Griffith Blakesley]

Confirmed with fresh profile on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b)
Gecko/20050130 Firefox/1.0+

Comment 7

[Fred Collier]

This appears to be working ok now with 20050206-01.  Was it 280754 that fixed
it?  Maybe 244946 is ok also?

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b) Gecko/20050206 Firefox/1.0+

Comment 8

[Jeff Walden [:Waldo]]

This is indeed WFM as confirmed by my home-built 20050208 Firefox on Linux.

Comment 9

[sairuh (rarely reading bugmail)]

this also w4m using 2005020911-trunk ffox on linux fc2.

Comment 10

[djpohly]

Thought this was WFM too, but I just discovered I'm still able to reproduce this on:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050213 Firefox/1.0+

but only if the Default=1 profile is not one of the first three on the list.

Comment 11

[tabmix.onemen]

in profileSelection.xul line 91:
      <listbox id="profiles" flex="1" rows="5" seltype="single"
remove the flex="1" and it seems to work
      <listbox id="profiles" rows="5" seltype="single"
i have no idea why

Comment 12

[Fred Collier]

After the checkin of the fix for...
"Bugzilla Bug 245135 - The using profile can be deleted after renaming"...
this bug is now WFM.

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b2) Gecko/20050321 Firefox/1.0+

Comment 13

[tabmix.onemen]

(In reply to comment #12)
> After the checkin of the fix for...
> "Bugzilla Bug 245135 - The using profile can be deleted after renaming"...
> this bug is now WFM.
> 
> Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8b2) Gecko/20050321 Firefox/1.0+

not for me. the selected profile is stil not focused unless it's the first
default profile

Comment 14

[Yoni Gilad]

This bug probably needs a port of the fix from seamonkey bug 120410.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Attachment: Hack that fixes it

This fixes it, and I have no idea why. I'm posting it in case it might help
someone find the correct fix.

Comment 16

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 179412 [details] [diff] [review]
Hack that fixes it

Also, the second hunk isn't related to this, so ignore it.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

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

Comment 18

[[e-mail]]

(In reply to comment #15)
>This fixes it, and I have no idea why.
It fixes it because the timeout gives Gecko a chance to construct the frame for
the listitem (assuming that it's visible, which it might not be for a long list
of profiles) thus making the XBL selected property available.

Note that you don't need to copy the existing local variable for the timeout.
Typically you either have special handling for "this" or you simply pass
everything as parameters to the timeout function.

Comment 19

[Jason Gallagher]

I am seeing this bug in nightly trunk builds for Windows 20050512 and 20050514
(probably occurs in 20050513, but I did not test that one).  This problem does
not occur in the official 1.0.4 build.

To be more specific I found the following to always recreate the "no highlight
or focus" bug:

1) Run Profile Manager on Firefox startup with 2 profiles, one of them being the
"default" profile.
2) If you were previously using the "default" profile, click on the second
(non-default) profile.  The first time after running the default profile
previously it will highlight the second profile.
3)Quit Firefox.
4) Re-Run Firefox with profile manager.  The second (non-default) profile will
not be highlighted, nor will it highlight if you click it.  It will also not
highlight if you click on the default and then back to the non-default profile.

Comment 20

[Raanan Barzel]

Problem still exists with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050629 Firefox/1.0+

Comment 21

[Teune van Steeg]

Attachment: cleaner version of gavin's patch: select listitem after all listitems are added

Selecting the selected profile after all profiles are being added to the
listbox, will make it also visibly selected.

Comment 22

[Teune van Steeg]

Comment on attachment 188546 [details] [diff] [review]
cleaner version of gavin's patch: select listitem after all listitems are added

After some more testing I find it doesn't work after all.

Comment 23

[Jaime Mitchell (use [e-mail] for email)]

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

Comment 24

[Mike Cowperthwaite]

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

Comment 25

[Mike Cowperthwaite]

This remark about the patch (comment 15):
> This fixes it, and I have no idea why.
contradicts this bug's "trivial" status.

Copied from the recent dupe:
> See a similar symptom when creating a custom mailview in TB or MailNews: 
> bug 254804 symptom 1 (which was unaffected by the patch at that bug).

Comment 26

[Nick Thomas [:nthomas] (UTC+12)]

Scott, any chance you can take a look at this bug before Fx & Tb 1.5 ? It would
be a nice piece of polish for users with multiple profiles (testers,
troubleshooters, user support etc).

Comment 27

[stefano]

HI,

  I am experiencing this problem on firefox 1.5 on windows XP. I did not
experience this in previous versions. I have two profiles, never added a third
profile. I am running XP professional 2002 service pack 2.
 Here is the user agent string: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Regards,
Stefano

Comment 28

[PikeUK]

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

Comment 29

[Dave Townsend [:mossop]]

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

Comment 30

[Mike Cowperthwaite]

See a similar symptom in yet another listbox at bug 307880.

Setting version to the branch, but the problem is in the trunk as well.

Comment 31

[Adam Guthrie]

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

Comment 32

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

The equivalent suite bug changed from using a listbox to a tree to fix this,
but I'm not sure that's really worth it, given this hack fixes the problem.

Comment 33

[:Gavin Sharp [email: [e-mail]]]

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

Comment 34

[:Gavin Sharp [email: [e-mail]]]

Trunk:
mozilla/toolkit/profile/content/profileSelection.js; new revision: 1.8;
1.8 Branch:
mozilla/toolkit/profile/content/profileSelection.js; new revision: 1.7.8.1;

Comment 35

[Worcester12345]

Is this one fixed on branch (1.8 key word?)?

Thanks.

Comment 36

[moz_bug_r_a4]

This is still reproducible when I have 6 profiles or more and the last used 
profile is after 5th. I think calling ensureElementIsVisible() can fix this.
The following code works for me with over 100 profiles.

        if (profile === gProfileService.selectedProfile) {
          setTimeout(function(a) {
            profilesElement.ensureElementIsVisible(a);
            profilesElement.selectItem(a);
          }, 0, listitem);
        }

Comment 37

[:Gavin Sharp [email: [e-mail]]]

Attachment: moz_bug_r_a4's patch

Good catch, I should have noticed that considering I'd just fixed bug 303520 :(

Comment 38

[Mike Connor [:mconnor]]

Comment on attachment 196382 [details] [diff] [review]
moz_bug_r_a4's patch

r=me, we should approve this for the same reason we approved the last patch,
namely that this carries no risk outside of profile manager.

Comment 39

[:Gavin Sharp [email: [e-mail]]]

Trunk:
mozilla/toolkit/profile/content/profileSelection.js; new revision: 1.9;

Comment 40

[:Gavin Sharp [email: [e-mail]]]

1.8 Branch:
mozilla/toolkit/profile/content/profileSelection.js; new revision: 1.7.8.2;

Thanks moz_bug_r_a4!

Comment 41

[Phil Ringnalda (:philor)]

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

Comment 42

[Phil Ringnalda (:philor)]

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

Comment 43

[CrazySmartid666]

I need help. Where is this file (profileselection.js) supposed to be located. In
terms of where my Hard Drive is C:\

Like C:\ApplicationData\

Comment 44

[Mike Cowperthwaite]

The fix for this bug is all well and good, but as noted in comment 25 and comment 30, there are similar issues with other listboxes in the program.

(from comment #18)
> the timeout gives Gecko a chance to construct the frame for
> the listitem [...] thus making the XBL selected property available.

Is there some way this could be handled differently?  Like, give the pre-
frame-construction object a means of accepting the 'selected' indicator, 
which it then applies *on its own* after the frame is built?

It's also not clear why the item is actually 'unselectable' -- what's 
preventing it from being displayed in blue when it's clicked *after* the 
dialog has been displayed?

It doesn't make sense to me to "fix" this problem in this way.  Setting the 'selected' property should just work. Similar caching for the 'ensureElementIsVisible' calls and other XBL-specific properties until the object is built would also be desirable.


Bug 307880 has a similar situation: a listbox with an 'unselectable' item immediately after the dialog is visible.  (The symptom from bug 254804 is somewhat different -- the 'unselectable' item is added to the listbox well 
after its creation, which is the same situation described for yet another 
listbox at bug 278453 comment 12.)

Comment 45

[Benjamin Smedberg]

I don't think we want to unit-test the actual PM UI, but we could/should probably come up with a minimized testcase.