The default bug view has changed. See this FAQ.

Profile manager only shows a random subset of available profiles

VERIFIED FIXED

Status

()

Core
XP Toolkit/Widgets: XUL
--
major
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: philor, Assigned: bz)

Tracking

(4 keywords)

Trunk
fixed1.8.1.22, fixed1.9.0.11, regression, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.0.x +
blocking1.8.1.next +
wanted1.8.1.x +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
STR:

1. Create enough profiles (6 should do it, though more increase the chances of scrolling fun) to have a scrollbar in the profile manager listbox, to make it easier to see.
2. Repeatedly start Firefox showing the profile manager, noting that even though you have a scrollbar on the listbox, you only see the names of a random 2, 3, 4 or 5 profiles. For bonus fun, scroll the apparently-useless scrollbar, noting that the names of things scrolled out of view will sometimes change as they are scrolled back into view.
3. hg update -r 0a030558e073 to get back behind the checkin for bug 432068
4. Repeat, noting that you see all the profile names, and that they remain the same while scrolled in and out of view.
Blocks: 432068
Created attachment 371096 [details] [diff] [review]
Fix

I missed the fact that |result| is used immediately after this to determine whether isAppend is true.  With the change from bug 432068, isAppend will always end up true, basically, even when doing an insert.  This will cause the listitems to be in the wrong order as a start, and will cause frames to not be created in some cases because the index |i| computed in this function in later calls won't match the listitem position in the childlist in the frame tree.  So we'll look for a frame for some other child content node than the one we really want, find it, and skip creating a frame.

This fix just avoids clobbering |result| too early.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #371096 - Flags: superreview?(roc)
Attachment #371096 - Flags: review?(roc)
Blocks: 486842
Oh, and I'll write up some reftests here too, tomorrow.
Component: Startup and Profile System → XUL
Product: Toolkit → Core
QA Contact: startup → xptoolkit.widgets
Component: XUL → XP Toolkit/Widgets: XUL
QA Contact: xptoolkit.widgets → xptoolkit.xul
Blocks: 486924
Created attachment 371156 [details] [diff] [review]
Now with reftests
Attachment #371096 - Attachment is obsolete: true
Attachment #371156 - Flags: superreview?(roc)
Attachment #371156 - Flags: review?(roc)
Attachment #371096 - Flags: superreview?(roc)
Attachment #371096 - Flags: review?(roc)
Attachment #371156 - Flags: superreview?(roc)
Attachment #371156 - Flags: superreview+
Attachment #371156 - Flags: review?(roc)
Attachment #371156 - Flags: review+
Attachment #371156 - Flags: approval1.9.1?
Comment on attachment 371156 [details] [diff] [review]
Now with reftests

Need this on branch too.
Attachment #371156 - Flags: approval1.9.1? → approval1.9.1+
Pushed http://hg.mozilla.org/mozilla-central/rev/eb964536fa10
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0ede9e602eb7
Keywords: fixed1.9.1

Updated

8 years ago
Duplicate of this bug: 487033

Updated

8 years ago
OS: Mac OS X → All
Hardware: x86 → All

Comment 8

8 years ago
I have just upgraded to 3.5b4pre and this seems to have resolved the problem i reported on Bug 487033

Best

Fred f.
Fred f., could you add the build Id of 3.5b4pre you're using as a comment to this bug? Also, since you've verified it on Shiretoko, can you do the same on trunk as well (and add that build Id too) ? Thanks!

Comment 10

8 years ago
This is from About Shiretoko:

  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090407 Shiretoko/3.5b4pre

What is Trunk? Do you mean the Firefox release I use?

If so then there was never a problem there as stated, even when Shiretoke was missing out some of the profiles, Firefox always displayed them all.

Will have to log of and on gain to get Firefox version

Best

Fred F.

Comment 11

8 years ago
Firefox version is:  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Fred, trunk would be the 3.6pre builds (based on Gecko 1.9.2pre).  Don't worry about those.
verified FIXED on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090413 Minefield/3.6a1pre ID:20090413031052
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
This fix is rolled into the branch patches in bug 432068, adding fixed keywords here for branch verification.
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.next+
Keywords: fixed1.8.1.22, fixed1.9.0.11
You need to log in before you can comment on or make changes to this bug.