Closed
Bug 424821
Opened 17 years ago
Closed 16 years ago
Listbox incorrectly rendered with vertical scrollbar
Categories
(Core Graveyard :: GFX: Win32, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 286456
People
(Reporter: scott.turner, Unassigned)
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; en-us) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13
Build Identifier: HEAD
In attached test case the resulting list box is initially rendered with a vertical scrollbar. Selecting an element re-renders the list box with out the vertical scroll bar.
I'll attach a XUL test case and screen captures as soon as I can get at the bug.
Reproducible: Always
Steps to Reproduce:
1. Click on list box to open it
2.
3.
Actual Results:
It is rendered with a vertical scroll bar even though all 5 options are visible.
Expected Results:
It should have been rendered with out a vertical scroll bar.
Click on an option causes the list box to be re-rendered without the vertical scrollbar.
Reporter | ||
Comment 1•17 years ago
|
||
Reporter | ||
Comment 2•17 years ago
|
||
Reporter | ||
Updated•17 years ago
|
Component: General → GFX: Win32
Product: Firefox → Core
Version: unspecified → Trunk
Reporter | ||
Comment 3•17 years ago
|
||
Updated•17 years ago
|
QA Contact: general → win32
Updated•17 years ago
|
Flags: blocking1.9?
Comment 4•17 years ago
|
||
At the moment, this doesn't keep users from actually using the product. However, we should fix this. Marking wanted-next+.
Is this a regression? Need a regression range if so.
Flags: wanted-next+
Flags: blocking1.9?
Flags: blocking1.9-
I am seeing this one too. In fact, I am having a hard time getting rid of this problem. As far as I can see, the problem occurs when rows<5 (or so), and while playing around with font-size and padding styles will sometimes help, I've not found a reliable method to prevent these unnecessary scrollbars (which make things ugly, if not unusable).
One thing that is different in my case: The scrollbars does not disappear when I click an item, but they do disappear when I try to scroll the scrollbar (be it by actually scrolling the bar or by clicking its down-button - Up-button won't work, probably because the list is at the top when first displayed).
I don't know if the fact that I'm populating the listbox dynamically, using .appendItem(), has anything to say?
If anyone knows about a decent workaround, please let me know (privacy[doht]lover[aht]gmail.com)
Update:
It would appear that the issue (at least the one I'm seeing) is related to dynamically setting listbox.selectedIndex (in this case to zero, to ensure that the first listitem is selected when the listbox is shown). I'm doing this in the onload event of the dialog.
If I remark this statement, I don't get the unnecessary scrollbars.
If I select any item but the first, I don't get the scrollbars.
If I use various other methods, such as listbox.toggleItemSelection, I still get the scrollbars.
Update-update:
(Sorry about the spamming)
Errata: If I select any item (including the first), I get the scrollbars. Only if I do NOT select an item during the load event, can I get rid of this issue.
My current "solution" (aka. "ugly fix"): I use setTimeout to select the item 150ms after the load event (which obviously only works if the dialog has been displayed by then - It is a compromise between chance of failure and the delay being too obvious).
Assignee | ||
Updated•16 years ago
|
Product: Core → Core Graveyard
Updated•16 years ago
|
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•