This is a "regression" from Firefox 2. I added quotes because, on Mac, we didn't support the Indian font face that's used in my testcase in Firefox 2. That's new to the trunk. When a <select> contains whatever Indian script that is in my testcase, the select displays much taller than those without it. See the testcase.

This happens in Windows too. Moving to Core::Layout. It's likely a dupe.

Other scripts cause this too, iirc. It may have to do with the "line-height" requested by a given font, too. I thought I'd seen this filed, but I can't find it off-hand, either :(

(Reed filed bug 425345 for Thai on Linux, too.)

FWIW here's a list of heights for the 0x0000-0xFFFF range I measured using JavaScript

(In reply to comment #6) > Created an attachment (id=316930) [details] > select boxes without options are smaller Yeah, that's another bug I've been meaning to file for ages. I think it's a Cocoa Widget native theme bug, though, because those look consistent in Carbonfox. I've had that screenshot and a matching one from Carbonfox sitting on my Desktop for months :(

Here's a second testcase, stripped from the real world (MediaWiki user preferences page) that shows how much larger this can get in comparison to Sam's testcase, which seems mild! It's like the extra height is cumulative, or there's one script in there whose fonts have overly-large height. Also note that removing the UTF-8 charset meta tag from the page (or presumably serving the page with a different content-type http header) causes the bug to disappear.

Shouldn't be bug 425345 and bug 428564 duped against this one because they describe the identical core issue? I don't think that different char sets should live in their own bug.

Marcia's is definitely an exact dupe of this one. It's possible Reed's is, too, and that platform/script differences are irrelevant to the actual bug, but I don't know enough about how we work with glyph metrics and such to say. John might be better positioned to answer that.

This would fix it, but it's nothing more than a hack.

It seems to me this is the right rendering.... we want to be making the <select> tall enough to fit any of the options, no?

Here's a comparison rendering (note that Gecko 1.9.0 and WebKit use different "base sizes" for the height of a normal <select>, so ignore that and just focus on the relation between the heights of the two <select>s in each screenshot.) Safari (and Gecko < 1.9) draw the <select> at a fixed size and still accomodate all the options without clipping. Gecko 1.9 and up draw the text at a fixed size (such that it all fits in the same sized box and at the same baseline, give-or-take a couple of pixels, without clipping), but *add* tons of useless padding between the baseline of the text and the bottom of the <select>.

> still accomodate all the options without clipping. Is that true no matter what characters are actually used in the indic text? > *add* tons of useless padding between the baseline of the text and the bottom > of the <select> Is that <select>-specific? How does similar text outside a <select> look in Gecko? What about in Safari?

The basic problem is that in scripts like this, there is a large discrepancy between the "typical" vertical extent of most text (e.g. what's likely to appear in a <select> on a Hindi web page) and the most extreme examples of high or low diacritics that might in theory be used (e.g., in classical Sanskrit). <select> would generally look best if based on the vertical extent of "typical" text; but the ascent and descent values in the font are likely to be set so as to encompass the tallest and deepest glyphs (to avoid potential clipping, which has traditionally been a problem if glyph images extend beyond the nominal ascent or descent of the font). Using Devanagari on Mac OS X as an example: data:text/html,<p style="font-size:400%"><span style="background:#0f0">abc &#x939;&#x93F;&#x928;&#x94D;&#x926;&#x940; xyz</span> Note how the vertical extent (as shown by the background color) is based on the default font, and may not completely encompass the Hindi text. This would be the basis for sizing a typical English-only <select> element. Explicitly selecting the Devanagari font shows its vertical extent: data:text/html,<p style="font-size:400%"><span style="background:#0f0">abc <span style="font-family:devanagari mt;background:#f00">&#x939;&#x93F;&#x928;&#x94D;&#x926;&#x940; &#x939;&#x942;&#x901;</span> xyz</span> Note how much "excess" space there seems to be below the glyphs. This is why our <select>s look so bad; they inherit all that apparent "padding", as the line as a whole takes on the maximum extents of the fonts used within it. However - and here's the cause of the problem - the font contains a bunch of "stacked" conjunct glyphs that I presume might be used, for example, in Sanskrit text. If one of these occurs with a diacritic beneath, we can finally see why the descent of the font is so deep: data:text/html,<p style="font-size:400%"><span style="background:#0f0">abc <span style="font-family:devanagari mt;background:#f00">&#x919;&#x94D;&#x915;&#x94D;&#x937;&#x94D;&#x92F;&#x942;&#x901;</span> xyz</span> So that usually-unwanted space is not just padding, it is there to ensure that none of the text is clipped even with particularly extreme character sequences. In "normal" usage, though, the result looks terrible.

(In reply to comment #19) > > still accomodate all the options without clipping. > > Is that true no matter what characters are actually used in the indic text? No. Testcase: data:text/html,<select><option>abc &#x939;&#x93F;&#x928;&#x94D;&#x926;&#x940; xyz</option></select><br><select><option>abc &#x919;&#x94D;&#x915;&#x94D;&#x937;&#x94D;&#x92F;&#x942;&#x901; xyz</option></select> This shows two <select>s, one that includes "typical" Hindi text, and one with an "extreme stack". The first example looks good in Safari, and poor in Firefox because of excessive whitespace below the text. However, in the example shows that the Firefox <select> actually fits the stacked conjunct and diacritic, whereas Safari clips the text. (You really have to zoom the display to see what's happening - which brings up a separate bug I'm about to file, if I don't find a dup).

(In reply to comment #21) > (You really have > to zoom the display to see what's happening - which brings up a separate bug > I'm about to file, if I don't find a dup). Never mind, that was bug 480265.

(In reply to comment #20) Apologies for the bugspam, but I just discovered that the testcases above don't work as intended when copied back from Bugzilla, because the space in the font name "devanagari mt" was lost in line-wrapping. Re-posting them with a %-encoded space, so I hope they work this time: data:text/html,<p style="font-size:400%"><span style="background:#0f0">abc <span style="font-family:devanagari%20mt;background:#f00">&#x939;&#x93F;&#x928;&#x94D;&#x926;&#x940; &#x939;&#x942;&#x901;</span> xyz</span> data:text/html,<p style="font-size:400%"><span style="background:#0f0">abc <span style="font-family:devanagari%20mt;background:#f00">&#x919;&#x94D;&#x915;&#x94D;&#x937;&#x94D;&#x92F;&#x942;&#x901;</span> xyz</span>

I just tried the testcase from comment 21 in IE8 (because I wanted to see what it does in this situation), and it doesn't show a single stacked glyph cluster; it shows a bunch of glyphs arranged horizontally. Is that just a bug in IE8?

(In reply to comment #24) > I just tried the testcase from comment 21 in IE8 (because I wanted to see what > it does in this situation), and it doesn't show a single stacked glyph cluster; > it shows a bunch of glyphs arranged horizontally. Is that just a bug in IE8? Not a bug, just a font difference. Lots of conjunct forms are optional; the text can be written as "strung-out" sequences of half-form characters or with halant glyphs, or it can be stacked into a special conjunct form, depending on the whim of the font designer (or the target language, etc).

Hmm. Any idea how I can exercise the stacked form in IE8 on Vista?

To see a comparable effect in IE, you need an OpenType font that includes stacking conjuncts. The Mangal font used by default in Windows doesn't have these. I was able to reproduce a similar issue using the free Sanskrit 2003 font and the attached testcase. This shows three <select>s. The first contains Latin text only; the second includes a stacked conjunct with diacritic below; and the third includes the same Devanagari text, but is explicitly styled in Sanskrit 2003. STR: install the Sanskrit 2003 font in Windows, and select it as the default font for Devanagari in IE. Then view the testcase. With IE7, at least, the middle <select> then shows clipping at the bottom of the text; how severe varies depending on the zoom level. The third <select>, which is explicitly styled using the Sanskrit font, becomes much larger vertically (and therefore doesn't clip, but would look bad with typical text content).

OK. So the key is that we size the combobox based on the height of its tallest option (as you can easily see by using different font-sizes for the different options), whereas it sounds like IE and Safari just size it based on the default font of the <select> and allow the text to be clipped if the resulting height is not sufficient for all the options in the <select>? We could certainly do the IE/Safari behavior here, but is it desirable?

Hmmm. Using different font-sizes for the options illustrates another slightly weird effect: data:text/html,<select><option>hello</option><option%20style="font-size:200%">world</option></select> Here, Safari shows a "normal-size" popup, but when you open the menu, the second item is displayed with large type. However, once you actually select it, it's shown at regular size in the closed popup. That makes a certain amount of sense, as the large type wouldn't fit. In Minefield, the popup is enlarged because of the large font of item 2, but when you select that item, it is still displayed at the default size in the closed popup. Which doesn't really seem right.

> it is still displayed at the default size in the closed popup Yeah, we generally consider that a bug...

(In reply to comment #28) > We could certainly do the IE/Safari behavior here, but is it desirable? Probably yes, at least in the case of <select>. There are also other contexts where the same metrics issue comes into play, as illustrated by coloring the backgrounds of <span>s in testcases above. E.g., if you have a contentEditable element or a text area with Latin-script content, and the user starts entering some Hindi text in it, we'll suddenly increase the line spacing (especially the descent of the line in question) based on those "extreme" metrics. This looks a bit weird too, though it's not as glaring as the <select> case. Note that all this is not unique to Indic fonts, it just happens that we're seeing some particularly extreme manifestations there. For a different aspect of the problem on Mac OS X, try this testcase: data:text/html,<select><option>abc العربي xyz</option></select> Here, the default Arabic font (Geeza Pro) used does NOT have its font metrics extended so that the "descent" value encompasses the bounding box of the deepest glyphs. As a result, it does not cause the <select> in Firefox to grow and look bad; but the text actually paints slightly beyond the bottom edge of the widget, into the area of its potential focus ring; then at that point you can see (zoom in) that the dots underneath the final Arabic letter are slightly clipped. In Safari, on the other hand, the text drawing is clipped to the intended "content area" inside the popup widget, and the dots underneath ي are completely lost. In this case the Firefox result, although it looks a little untidy, seems preferable. Overall, it seems to me that the Safari/IE control-sizing behavior is better, but in the event that the text is particularly tall/deep, it's better not to clip it but to allow the text drawing to project beyond the widget frame. The Arabic example shows that we can handle this to a limited extent (in the space where the focus ring might be drawn), but I don't think we can fully support it for arbitrary amounts of glyph projection until we split overflow rects into separate "paint" and "structural/scrolling" overflow.

(In reply to comment #28) > We could certainly do the IE/Safari behavior here, but is it desirable? I somewhat prefer our current behavior of making enough room for whichever option is selected (over the IE/Safari behavior), but I'm open to alternatives if there are good ones.

It seems as if this issue has went away over time as the box does not change size depending on the text inside the box. I will change this bug as works for me. Please reopen if this issue reoccurs.