486848 - Profile manager only shows a random subset of available profiles

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Phil Ringnalda (:philor)]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

Oh, and I'll write up some reftests here too, tomorrow.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Now with reftests

Comment 4

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 371156 [details] [diff] [review]
Now with reftests

Need this on branch too.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/eb964536fa10

Comment 6

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0ede9e602eb7

Comment 8

[Fred Flange]

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

Best

Fred f.

Comment 9

[Aakash Desai [:aakashd]]

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

[Fred Flange]

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

[Fred Flange]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fred, trunk would be the 3.6pre builds (based on Gecko 1.9.2pre).  Don't worry about those.

Comment 13

[Aakash Desai [:aakashd]]

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

Comment 14

[Daniel Veditz [:dveditz]]

This fix is rolled into the branch patches in bug 432068, adding fixed keywords here for branch verification.

Comment 15

[Firefox Bug Husbandry Bot]

Moving to Core:XUL per https://bugzilla.mozilla.org/show_bug.cgi?id=1455336