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.

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

Also see this with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040715 --> Browser

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.

> Todays Mozilla suite 1.8a3 with modern nor with classic That was a smoketest blocker today; it's fixed. Please retest tomorrow's builds.

(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.

According to comment 7 this was a smoketest blocker, but its still broken with classic theme, trunk build 20040922, nominating for blocking1.8a4.

Roc or Neil, can you help here. This probably blocks 1.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.

you are a genius!

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

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.

Comment on attachment 160029 [details] [diff] [review] fix a=asa for 1.8a4 checkin. Thanks for the quick turnaround.

Is this something that also could go into the aviary branch? Or is it too risky?

checked in

This could go in Aviary/1.7 if desired.

Verified with Mozilla trunk build 2004-09-27-17-trunk (1.8a4 rc)

Comment on attachment 160029 [details] [diff] [review] fix a=asa for aviary and 1.7 checkin.

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.

*** Bug 221435 has been marked as a duplicate of this bug. ***