12 years ago
4.35 KB, image/png
434 bytes, application/vnd.mozilla.xul+xml
1019 bytes, patch
|Details | Diff | Splinter Review|
1.02 KB, patch
|Details | Diff | Splinter Review|
if there are 6 or more profiles, profile chooser doesn't show all at once. in this case there's a scroll bar on the right. next, scroll the list using mouse. then the chooser doesn't show the profiles that were hidden. I've seen this since 3.0a2pre(20061222). same on 20061228.
My regression range from my random assortment of builds is from 2006-12-06 21:00 to a few minutes before the reflow branch landed, roughly http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&date=explicit&mindate=2006-12-06+21%3A00%3A00&maxdate=2006-12-07+21%3A00%3A00&cvsroot=%2Fcvsroot from which bug 344228 seems likely (other than the whole "I can't see it, and don't even know if that the right number or a typo" thing). Unfortunately, it doesn't back out happily, and I seem to be making wrong choices resolving conflicts, so I can't say for sure. Testcase in a second.
Component: General → XP Toolkit/Widgets: XUL
OS: Windows 2000 → All
Product: Firefox → Core
QA Contact: general → xptoolkit.xul
Hardware: PC → All
Summary: [profile chooser] 6+ profiles aren't shown correctly when using scroll bar → Scrolled items in listbox are invisible (Firefox profile manager doesn't show 6+ profiles correctly)
Created attachment 249905 [details] testcase Alice through Ellen are shown on load; drag the scrollbar thumb, or click in the gutter below it, and Frank shows up, but Patrick and Whoopi are invisible, though you can get to them by selecting Ellen and pressing the down-arrow key instead. I don't have any opinion about the way that without the chrome://global/skin/ stylesheet I included out of habit, Frank doesn't show up when you scroll, either.
Does this occur on the branch as well? Bug 344228 also had a branch patch, although different.
OK, I'll have a patch for this soon.
Assignee: nobody → enndeakin
Created attachment 249928 [details] [diff] [review] Get the right frame to use as the scroll mediator
Comment on attachment 249928 [details] [diff] [review] Get the right frame to use as the scroll mediator OK, wait, this isn't working right
Created attachment 249931 [details] [diff] [review] This is better. Handles listboxes and trees This change is needed because listboxes have a scrollframe in-between
> Does this occur on the branch as well? Bug 344228 also had a branch patch, > although different. So I don't have to dig it out of CVS logs again, that would be after 2006-12-21 13:40
Note that the branch patch in bug 344228 is mostly a Mac oriented patch.
Same (or more so) behavior in 20061229 BonEcho/220.127.116.11pre on Windows - profiles hide, and even Frank doesn't show up scrolling the testcase (though I don't remember now whether I looked at whether the first out of sight item shows on trunk with anything other than Mac).
I wouldn't expect to block the branch on profile manager, but it also affects the feed reader selection in prefs, and probably other user-visible things I'm not thinking of yet.
Let's get this patch reviewed and some approval requests so we can get this on the 1.8 branch asap for testing.
Flags: blocking18.104.22.168? → blocking22.214.171.124+
Address widget in mail compose is a listbox, too, so I hope we aren't about to do a Tb or Sm release.
Checked this in on trunk
Created attachment 250353 [details] [diff] [review] branch version of patch
Has this been tested sufficently that it can be checked in on the branch?
Did you mean to resolve this bug fixed, so the branch drivers would be able to see it as something that had a trunk patch baking? And did you mean to "?" the the approval126.96.36.199 flag, so they would see you had a branch patch you wanted to land?
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 250353 [details] [diff] [review] branch version of patch Approved for the 1.8 branch, a=jay for drivers.
Attachment #250353 - Flags: approval188.8.131.52? → approval184.108.40.206+
Since this appears to be a recent regression on the 1.8 branch, can someone please test on the 1.8.0 (FF1.5) branch to see if this problem exists on recent nightlies?
Yep, Windows Firefox 220.127.116.11pre 20070108 has the same thing in the profile manager, and although 1.5 doesn't have the feed reader selection to show it to average users, I assume 1.8.0 Thunderbird builds have the same problems bug 365354 reported in the addressing widget composing mail.
Flags: blocking18.104.22.168? → blocking22.214.171.124+
Whiteboard: regressed by bug 344228?
Comment on attachment 250353 [details] [diff] [review] branch version of patch Approved for 1.8.0 branch, a=dveditz for drivers
Attachment #250353 - Flags: approval126.96.36.199+
Verified fixed for 188.8.131.52 - 184.108.40.206 and trunk on: verified with: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a2pre) Gecko/20070203 Minefield/3.0a2pre ID:2007020304 [cairo] for trunk Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:220.127.116.11pre) Gecko/20070204 Firefox/18.104.22.168pre ID:2007020405 for 22.214.171.124 Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:126.96.36.199pre) Gecko/20070205 BonEcho/188.8.131.52pre ID:2007020505 for 184.108.40.206 also on Linux Fedora FC 6
Status: RESOLVED → VERIFIED
Keywords: fixed220.127.116.11, fixed18.104.22.168 → verified22.214.171.124, verified126.96.36.199
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.