Closed Bug 251586 Opened 19 years ago Closed 18 years ago

select tag with multiple and size set create lists with out scrollbars if the option tag labels are all numeric.

Categories

(SeaMonkey :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: dwhite, Assigned: roc)

References

()

Details

(4 keywords)

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

creating a list box using <select name="list" multiple size="5"> or <select
name="list" multiple="muiltiple" size="5"> and with options that are all numeric
as in <option value="one">1</option> produces a list box without a scrollbar. 
The same select tag with the option lables changed to text as in <option
value="one">one</option> produces the expected scrolling list box.

Reproducible: Always
Steps to Reproduce:
1. Create a form with a select tag using multiple and size and provide only
numeric options.
2. View the page in Firefox


Actual Results:  
List boxes without scrollbars

Expected Results:  
List boxes with scrollbars

I have viewed this bug in IE and Netscape 7.1 and all list boxes appear
properly.  I have tried this on Firefox 0.9.2 and 0.9.1 both on Windows XP on 2
separate computers and it appears the same way on both.
Attached file This is an HTML test case. (obsolete) —
The attached HTML page has 3 list boxes the first shows up correctly (with
scrollbars) the second and third do not (no scrollbars).  This page reders that
same on multiple WindowsXP boxes and in Firefox 0.9.1 and 0.9.2
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040707
Firefox/0.9.0+
CONFIRMED ->NEW
Status: UNCONFIRMED → NEW
Ever confirmed: true
Also see this with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3)
Gecko/20040715

--> Browser
Assignee: firefox → general
Component: General → Browser-General
Product: Firefox → Browser
QA Contact: firefox.general → general
Version: unspecified → Trunk
additional:
if the FIRST(important) <option> is not a letter than it does not work.
I tried space , dot , questionmark etc, 
After more testing:

Works in:
Mozilla suite 1.7.1 with modern

Does NOT work in:
Todays Mozilla suite 1.8a3 with modern nor with classic
Mozilla suite 1.7.1 with classic
Todays Firefox branch build

It doesnt help to update the code with valid (current testcase has errors) that
validates.
Severity: normal → major
Keywords: testcase
Attachment #153310 - Attachment is obsolete: true
> Todays Mozilla suite 1.8a3 with modern nor with classic

That was a smoketest blocker today; it's fixed.

Please retest tomorrow's builds.
Keywords: qawanted
(In reply to comment #7)
> Please retest tomorrow's builds.

Modern now works as expected. But I still see this in trunk build 20040716 with
classic theme. Can attach screenshot if you want.

As mentioned before, this doesnt work on the AVIARY branch nor with 1.7.1 and
classic.
Keywords: classic
According to comment 7 this was a smoketest blocker, but its still broken with
classic theme, trunk build 20040922, nominating for blocking1.8a4.
Flags: blocking1.8a4?
Roc or Neil, can you help here. This probably blocks 1.8a4.
Assignee: general → roc
Flags: blocking1.8a4? → blocking1.8a4+
Someone decided that an area that is less than the size of a scrollbar should
never have scrollbars. In Modern, this means that an area less than 30 pixels
wide will never have a vertical scrollbar, while in Classic the cut-off point is
36 pixels, at least in my build (this may vary depending on native theming).

This scheme was really designed for small scrollable frames (note: it doesn't
even work very well in Classic because the minimum scrollbar length is twice its
width, so the horizontal scrollbar disappears before the vertical one does, then
makes a brief reappearance; in Modern however we can easily squash a scrollbar
down to 12 pixels long even though they are 15 pixels wide!); unfortunately it
is also being applied to selects where it doesn't make any sense because the
dimensions are constrained from the inside rather than the outside.
OK, this is probably mine. Need to hack nsGfxScrolLFrame. I'll take a look tonight.
I can't reproduce with my GTK2 theme. Are there any Seamonkey themes I can
download that will do this?
This test case (URL field) shows in both Classic and Modern for me.
Attached patch fixSplinter Review
This should fix it.

I'm a bit concerned about regressions though. This code is fragile.
Comment on attachment 160029 [details] [diff] [review]
fix

David, maybe you could take a look at this. I don't know if the aXY changes are
needed, but they're obviously correct. The main change is:
-   if (size >= aSbSize) {
+   if (size >= 0) {
Which looks more like the right code, and behaves correctly in my tests ...
Attachment #160029 - Flags: superreview?(dbaron)
Attachment #160029 - Flags: review?(dbaron)
Attached file testcase
Resizing the window containing this testcase shows what happens when a very
small overflow:auto DIV is manipulated. It looks good to me, with the patch.
The only problem I can see is that if you make the window simultaneously
narrower and taller, then the scrollbar oscillates from being horizontal to
being vertical and back again. Both are correct; there's only room for one
scrollbar and no real rule to say which one whould be present. I'd like to
favour vertical and the current code tries to do that, but not hard enough. The
current code is too messy to fix properly easily. We really need the HTML
scrollbar refactoring I've been working too slowly on...
Comment on attachment 160029 [details] [diff] [review]
fix

>    // not enough room? Yes? Return true.

r+sr=dbaron, although I think the number of negatives in this comment is
incorrect.
Attachment #160029 - Flags: superreview?(dbaron)
Attachment #160029 - Flags: superreview+
Attachment #160029 - Flags: review?(dbaron)
Attachment #160029 - Flags: review+
Comment on attachment 160029 [details] [diff] [review]
fix

a=asa for 1.8a4 checkin. Thanks for the quick turnaround.
Attachment #160029 - Flags: approval1.8a4+
Is this something that also could go into the aviary branch? Or is it too risky?
checked in
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
This could go in Aviary/1.7 if desired.
Flags: blocking-aviary1.0?
Verified with Mozilla trunk build 2004-09-27-17-trunk (1.8a4 rc)
Status: RESOLVED → VERIFIED
Comment on attachment 160029 [details] [diff] [review]
fix

a=asa for aviary and 1.7 checkin.
Attachment #160029 - Flags: approval1.7.x+
Attachment #160029 - Flags: approval-aviary+
This doesn't appear to have landed on the aviary or 1.7.x branches. Time is
short for the aviary release.
Checked in on 1.7 and aviary.
Flags: blocking-aviary1.0?
*** Bug 221435 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.