Closed Bug 279497 Opened 18 years ago Closed 17 years ago

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

Categories

(Toolkit :: Startup and Profile System, defect)

1.8 Branch
defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla1.8beta5

People

(Reporter: djpohly+bmo, Assigned: Gavin)

References

Details

(Keywords: fixed1.8, regression)

Attachments

(1 file, 3 obsolete files)

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.
Keywords: regression
Version: unspecified → Trunk
I saw this on yesterday's Mac OS X Firefox.
I only see this once a new profile is created using a current nighly build. I do
not see this on Mozilla trunk builds.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking-aviary1.1?
OS: Windows XP → All
Hardware: PC → All
profile manager is not exposed UI, not a blocker.
Severity: normal → trivial
Flags: blocking-aviary1.1? → blocking-aviary1.1-
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.
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+
Confirmed with fresh profile on Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b)
Gecko/20050130 Firefox/1.0+
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+
This is indeed WFM as confirmed by my home-built 20050208 Firefox on Linux.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
this also w4m using 2005020911-trunk ffox on linux fc2.
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
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
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+
(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
Assignee: benjamin → nobody
Status: REOPENED → NEW
Component: Startup and Profile System → XRE Startup
Flags: blocking-aviary1.1-
Product: Firefox → Toolkit
Version: Trunk → unspecified
This bug probably needs a port of the fix from seamonkey bug 120410.
Attached patch Hack that fixes it (obsolete) — Splinter Review
This fixes it, and I have no idea why. I'm posting it in case it might help
someone find the correct fix.
Comment on attachment 179412 [details] [diff] [review]
Hack that fixes it

Also, the second hunk isn't related to this, so ignore it.
*** Bug 289935 has been marked as a duplicate of this bug. ***
Summary: Selected profile does not always appear focused → Selected profile in profile manager does not always appear focused/highlighted
(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.
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.
Flags: blocking1.8b3?
Flags: blocking1.8b3? → blocking1.8b3-
Problem still exists with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050629 Firefox/1.0+
Selecting the selected profile after all profiles are being added to the
listbox, will make it also visibly selected.
Attachment #188546 - Flags: first-review?(mconnor)
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.
Attachment #188546 - Attachment is obsolete: true
Attachment #188546 - Flags: first-review?(mconnor)
*** Bug 301185 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary2.0?
*** Bug 304912 has been marked as a duplicate of this bug. ***
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).
Severity: trivial → minor
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).
Flags: blocking1.8b5?
Flags: blocking1.8b5?
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
*** Bug 307716 has been marked as a duplicate of this bug. ***
*** Bug 307890 has been marked as a duplicate of this bug. ***
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.
Flags: blocking1.8b5?
Version: unspecified → 1.8 Branch
*** Bug 307888 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — Splinter Review
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.
Assignee: nobody → gavin.sharp
Attachment #179412 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #195574 - Flags: first-review?(mconnor)
Whiteboard: [patch-r?]
Whiteboard: [patch-r?] → [patch-r+][checkin needed]
Whiteboard: [patch-r+][checkin needed] → [patch-r?]
*** Bug 308420 has been marked as a duplicate of this bug. ***
Attachment #195574 - Flags: first-review?(mconnor) → first-review+
Attachment #195574 - Flags: approval1.8b5+
Flags: blocking1.8b5? → blocking1.8b5+
Flags: blocking-aviary2.0?
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;
Status: ASSIGNED → RESOLVED
Closed: 18 years ago17 years ago
Keywords: helpwantedfixed1.8
Resolution: --- → FIXED
Whiteboard: [patch-r?]
Target Milestone: --- → mozilla1.8beta5
Is this one fixed on branch (1.8 key word?)?

Thanks.
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);
        }
Good catch, I should have noticed that considering I'd just fixed bug 303520 :(
Attachment #195574 - Attachment is obsolete: true
Attachment #196382 - Flags: first-review?(mconnor)
Attachment #196382 - Flags: approval1.8b5?
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.
Attachment #196382 - Flags: first-review?(mconnor) → first-review+
Trunk:
mozilla/toolkit/profile/content/profileSelection.js; new revision: 1.9;
Keywords: fixed1.8
Attachment #196382 - Flags: approval1.8b5? → approval1.8b5+
1.8 Branch:
mozilla/toolkit/profile/content/profileSelection.js; new revision: 1.7.8.2;

Thanks moz_bug_r_a4!
Keywords: fixed1.8
*** Bug 309347 has been marked as a duplicate of this bug. ***
*** Bug 310252 has been marked as a duplicate of this bug. ***
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\
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.)
I don't think we want to unit-test the actual PM UI, but we could/should probably come up with a minimized testcase.
Flags: in-testsuite?
Component: XRE Startup → Startup and Profile System
QA Contact: benjamin → startup
You need to log in before you can comment on or make changes to this bug.