Height of SELECT widget (set with CSS) is too small




13 years ago
3 years ago


(Reporter: heiko.selber, Unassigned)



Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(Not tracked)



(3 attachments)



13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20060111 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/20060111 Firefox/

In an HTML page that uses a CSS definition for SELECT widgets, the widget is too small to accomodate the entire height of the text, e.g. when the font size is 11px and the select height is 12px.

This is different than the behavior of IE, and has unfortunately made my company decide to abandon Firefox for the project I am currently working in.

Reproducible: Always

Steps to Reproduce:

Consider this example:

####file select.css:
select { font-size:11px; height:12px; font-family:verdana,  Arial;}

####file example.html:
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <link rel="stylesheet" type="text/css" href="select.css">

  <body >
    <select name="selectwidget">
      <option selected>Option 1</option>
      <option >Option 2</option>

Actual Results:  
The option text is only half visible.

Expected Results:  
The text should be entirely visible.

This bug may be a duplicate of bug # 136093, but I am not sure.

This may not be considered a bug after all, based on what I read there.

OTOH, I read in bug # 184478 'Right now the guideline I'm following is "render like IE"'.


13 years ago
Assignee: nobody → dbaron
Component: General → Style System (CSS)
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
Assignee: dbaron → nobody
Component: Style System (CSS) → Layout: Form Controls
QA Contact: ian → layout.form-controls
WFM on trunk
Created attachment 252278 [details]
Testcase from comment #0

Confirmed the issue with Firefox using this testcase. Can't reproduce it on the trunk.
OK, upon further analysis it appears that the reason the testcase worked earlier for me is because I was using the Luna Element 5 theme instead of standard Windows XP Luna. When I switched back to XP Luna, the testcase also fails with the current trunk.
Ever confirmed: true
Version: 1.8 Branch → Trunk
So... does anything change if you set "-moz-box-sizing: content-box" on the <select>?

Does IE do border-box or content-box sizing here?  Or does it vary for width vs height?  Or does it just have less internal padding/border than we do?  That is, how do the heights of auto height selects compare with IE?
So testing indicates that IE increases the height of the control as the font size is increased, even if the control has a specified height.  This makes sure that the control is always tall enough for the text.  We should just do the same.

Comment 6

12 years ago
Created attachment 276162 [details]
A comparison of IE7 and Firefox's rendering with the example.

Comment 7

12 years ago
The cause seems to be that Firefox has a minimum font size preference: font.minimum-size.x-western which is set to 12 by default.

Comment 8

12 years ago
font.minimum-size.x-western was a custom setting that I had made. I didn't notice that it was bold. Whoops

As long as font.minimum-size.x-western doesn't interfere, then -moz-box-sizing: content-box; appears to solve the problem, as Boris Zbarsky originally suggested.
Emery says IE7 simply ignores style-specified height on comboboxes.  Perhaps we should just do that as well?

Comment 10

12 years ago
Actually this just means that the only reason it worked for IE is because it completely ignored the height and sized the box to fit the text content, so if he wants Firefox to behave the same he needs to just remove the height: 12; property. It's not a Firefox bug, it's an IE bug.
Well.  As I see it we have three options:

1)  Mark bug invalid
2)  Do what IE does
3)  Do what I said in comment 5 (but don't ignore too-big heights), with the
    padding going away before we start expanding the control.

I'm really tempted by #3, to be honest.  It's a good compromise between actually following the height style and making such controls usable.  It's also the most annoying to do, of course... :(

Flags: blocking1.9?
Keywords: compat

Comment 12

12 years ago
I say #1. I don't think the compromise solves the problem. I can only guess that he wants the element to be an absolute height so that it lines up pixel perfect with something else. Using content-box sizing frees up some more space so that the text fits, the same could have been accomplished by increasing the height, but it doesn't mimic the behavior of IE which ignores the height all together. The only way to do that is to remove the height definition that Firefox respects and IE doesn't.
dbaron says #2 if that's really what IE does.

Comment 14

12 years ago
I'm OK with #3 as long as text that isn't cut off is still treated correctly (as you described). I don't think that IE compatibility should consequently break proper usage, as #2 does.
Created attachment 276400 [details] [diff] [review]
Patch doing #2 in case we want it sometime

In practice, this ends up being equivalent to "min-height: intrinsic" or something along those lines, since the padding is always claimed to be 0, even when there's obvious padding coming from the native theme...
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
The testcase still reproduces on Win 7, but no longer on Ubuntu with https://bugzilla.mozilla.org/show_bug.cgi?id=1230065#c22.

A larger font size still reproduces on Ubuntu.
data:text/html,<select style="height: 20px; font-size: 20px;"><option>Help Me
See Also: → bug 429802
You need to log in before you can comment on or make changes to this bug.