BUILD: 2002-03-12 morning trunk build STEPS TO REPRODUCE: 1) Load http://bugzilla.mozilla.org/query.cgi 2) Look at the "Status" multiple select 3) Notice the ugly scrollbar-width white space on the right We should either have a disabled scrollbar there or not have the space.
Well the space should be there to avoid reflows on changing the number of options. I kind of like not having a scrollbar. Surely we can add that dynamically, into the space where we are now, no? That's what the listbox in Edit > Prefs > MailNews > Send Format > Plain Text domains does (although there are other problems with it).
Well... Except that the <select> is sized to be only as wide as the stuff in it (unlike the outliner in prefs, which is fixed-width and crops). This means that people expect it to shrink-wrap the contents. We currently only do that when there is a scrollbar.
Created attachment 73713 [details] How some browsers do it Ok. More datapoints on various implementations: 1) NS4/Unix -- the scrollbar is absent, as is the space for it 2) Mozilla/Unix (non-XBL controls) -- scrollbar is present and disabled 3) IE5/Solaris -- scrollbar is absent, space for it present. _But_ selecting an option draws the dark background all the way across the <select>, not stopping at the (nonexistent) scrollbar, unlike Mozilla with XBL controls See attachment to see how these look.
So the upshot is that I'd be fine with the IE5 approach...
hmm IE5 approach, I think that wouldn't be so easy
There will be no blank area, but disabled scrollbar instead.
*** Bug 130642 has been marked as a duplicate of this bug. ***
nsbeta1+ per nav triage team, adt3
removing nsbeta1+ on XBLFC bugs, these are out for MachV.
XBLFC are out for mozilla1.0.
XBL form control bugs are no longer *especially* relevant to anyone.