396096 - h4 tag before a combobox changes the combobox's internal text positioning

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, defect)

Description

[Josh Aas]

Attachment: test case 1

Whether or not you have an h4 tag before a combobox changes its internal text positioning. This shouldn't happen.

Repro:
1. Save "test case 1", open it in current trunk
2. Note the position of the text in the combobox
3. Edit the test case's source to uncomment the h4 tag
4. Open the testcase with h4 uncommented, note that the positioning of the text in the test case has changed

Comment 1

[Colin Barrett [:cbarrett]]

Looking at Safari, the position of the text in the <select> is correct when the h4 is not present. I checked this by counting the number of non-black pixels above the ascender of the h.

Safari, it's 3 consistently.
Minefield, it's 3 without the h4, and 2 with.

Comment 2

[Josh Aas]

That doesn't really mean much because our border could be incorrect in order to compensate for the layout bug. We need to get the layout bug fixed (consistent rendering with or without that h4 in the test case) before we can figure out how we should be setting up the control.

Comment 3

[philippe (part-time)]

I don't think the h4 is strictly necessary. I can have the 'chrome' part (aqua layer) of the widget move up or down by 1~2px only by changing the line-height.
The label (text part) of the widget is always correctly aligned with text next to the widget, though.
I'll attach a test case next.

Probably the use of h4 makes this more visible, the default margin for h4 is 1.33em; at 16px font-size, that translates to 21.28px.

Comment 4

[philippe (part-time)]

Attachment: test case 2

With 'Lucida Grande' as font and 1.4 as line-height, this displays correctly on my side.
Save locally, play with the value for line-height: 1.3, 1.5,... and see one or the two select boxes move incorrectly. Changing font-family gives different results.

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK, I can't reproduce this on Linux.  So some questions:

1)  Is this a problem with "-moz-appearance: none"?
2)  Is it a problem if the h4 is replaced by a <p>?
3)  What if the h4 styles from html.css are applied to that <p>?  What style
    makes the problem appear, if any?

This is basically looking like some sort of font selection weirdness; I believe we have some on file for Cairo.

Comment 6

[Boris Zbarsky [:bzbarsky]]

In particular we had a bug on Linux, iirc, where the font returned would sometimes be a full pixel off in size depending on what text came before that point....  That was in code that's not used on Mac, but maybe we have a similar Mac issue?

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Since changing the line-height makes a difference, I suspect this is a rounding issue with subpixel vertical coordinates. We always round the text baseline to the nearest Y pixel, maybe we're making different rounding decisions for the combobox theme background.

Comment 8

[philippe (part-time)]

I revisited the test case 2 with todays build on 10.4.10 ppc - changing the line-height as outlined in comment 4 (I use 1.2 up to 2.5). I modified the test case slightly, adding a couple of descenders in the option (North-jpq); that makes it more easy to see possible shifts.
The results were _much_ better than they were, and very close to what Webkit does. The height of the combobox is different (20px for Gecko, 18px for WebKit, according to the respective inspectors).

Adding a <p> with the same styling as an <h4> as suggested in comment 5 did not make any difference. Changing the margin on the paragraph (using 1em, 1.13em, 1.23em) did not cause display problems for the combobox either.

I wonder if bug 396101 did improve things here.

Comment 9

[Colin Barrett [:cbarrett]]

(In reply to comment #7)
> Since changing the line-height makes a difference, I suspect this is a rounding
> issue with subpixel vertical coordinates. We always round the text baseline to
> the nearest Y pixel, maybe we're making different rounding decisions for the
> combobox theme background.

The rounding decision we make is floor(y + 0.5). There's an //XXX about figuring out the best way to do that, but that sounds like what native theme stuff does too. Of course, in twips to app units we might be losing some precision as well?