User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030427 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030427 A scrollbar appears in multiple select box when not needed. In Mozilla 1.3 this scrollbars was shown but it was faded. Reproducible: Always Steps to Reproduce:

This is low priority. It's a consequence of the switch to Gfx scrollbars; I guess we just don't disable those scrollbars when we should.

Setting the ? flag for 1.7b to get some attention. Not a blocker, but a very visible confusing regression that was introduced after Mozilla 1.3

If you really want this fixed I think we need native theme support for disabled scrollbars.

Well, we do support disabled scrollbars. It's really up to the theme whether a scrollbar with no range looks disabled or not. What does IE do? Does our Windows theme code need tweaking? Brian?

IE and Opera doesnt show the scrollbar, but leaves space for it. Older Mozilla versions showed it, but disabled.

This is a bit odd, Mozilla does the same as IE/Opera on the fist dropdown, but not on the second one. Due to that it is longer than the default size? Adding a width to the second one does not change anything.

I see active scrollbars in both selects in attachment 2 [details] [diff] [review]. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040219 Firefox/0.8.0+

Make that attachment 141750 [details]

"Don't show a scrollbar but leave space for it" would effecively require a new overflow property. That could be done. It would probably be easier to implement "don't show a scrollbar and don't leave space for it" but that might cause problems. For one thing, it might become hard to tell that a listbox is actually a form control.

This screenshot shows the inconsistent (Windows XP) that I mentioned in comment 7

Looks like IE is adding an extra internal border to make it more obvious that the listbox is a form control. I'd like to have something like that added before we remove the scrollbar.

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

not going to block the release for this.

This is very visible on OS X. The scrollbar handle actually can be moved, altought there's nothing to scroll if the content of the (multi)select (or just a select with the size set) is smaller than the select height. This is very disturbing on the lineto.com site, where the main navigation consits of 5 select elements.

Indeed, very annoying on OS X: e.g. http://bugzilla.mozilla.org/query.cgi (Status, Resulution, etc.). Is this really the same as the original bug? The description says "multiple select", but on OS X it's reproducable with any <select> having the "size" attribute set, even if the "multiple" attribute is not present.

The first testcase showing inconsistency has some bad HTML in it: <select size="5" multiplemultiple> Removing the 'multiplemultiple' doesn't change anything though. Also, note that if the number of OPTIONs is larger than the size of the SELECT, no scroll bar appears, though you can use the arrow keys to get to the clipped options. Also, note that the behavior of the scrollbar not appearing only occurs on lists of a single character. The style properties 'scrolling' and 'overflow' when set on the SELECT have no effect on the visibility of the scrollbar... which is assuming it's even valid to use those on SELECT elements. Note that the behavior of the superficially similar TEXTAREA element, is what I would call correct: a scrollbar appears only when necessary, and in fact, it's appearance can cause existing text to be reformatting, vis-a-vis wordwrapping.

This seems to be a dupe of bug 76197, now that that one is fixed the scrollbars look like expected. Though the testcases here show another bug, no scrollbars when all options are numbers, but that bug 251586, duping. *** This bug has been marked as a duplicate of 76197 ***

Sorry - but this does not seem to be fixed. With: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041110 Firefox/0.9.1+ I'm still seeing enabled (but useless) scrollbars on https://bugzilla.mozilla.org/query.cgi (Status, Resolution, Severety, and Priority ).

Uri, this is a duplicate, any comments should be done in the original bug. *** This bug has been marked as a duplicate of 76197 ***

OK, my apologies. I saw that bug 76197 was marked as FIXED, and I incorrectly assumed this meant that it is fixed for Firefox trunk builds as well. Since this bug (203645) is not fixed on Firefox trunk builds, I (again, incorrectly) concluded that it is not really a duplicate.

In Firefox 1.01, I still get this wrong behavior. I doubt that this was fixed, but I'm not into the details of the various trunks of Mozilla, so I'm not sure wether Firefox 1.01 is actually supposed to already contain the fix. Some insight on this would be very much apprecheated. This bug is very disturbing on our website http://www.lineto.com, where the select fields with the size attribute set are one of the main design elements (resulting in a multi line select), and the scrollbars mostly do nothing (there's nothing to scroll) but they are allways displayed in an active state (Refer to the screenshot attached on 2004-05-06 18:58 PST)

(In reply to comment #23) > In Firefox 1.01, I still get this wrong behavior. This fix is not in 1.0.1, it will be in Firefox 1.1