Open Bug 328035 Opened 18 years ago Updated 2 years ago

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

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

People

(Reporter: heiko.selber, Unassigned)

References

Details

(Keywords: compat)

Attachments

(3 files)

Testcase from comment #0
429 bytes, text/html
Details
A comparison of IE7 and Firefox's rendering with the example.
4.63 KB, image/png
Details
Patch doing #2 in case we want it sometime
4.28 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

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:
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>Example</title>
    <link rel="stylesheet" type="text/css" href="select.css">
  </head>

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

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"'.
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
Confirmed the issue with Firefox 2.0.0.1 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.
Status: UNCONFIRMED → NEW
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.
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.
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?
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
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.
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.
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: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
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: → 429802
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: