645009 - Incorrect rendered decimal(!) width in pixels for select elements in FF4 (RC2)

Status: RESOLVED INVALID

(Core :: Layout: Form Controls, defect)

Description

[John van Keulen]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

The issue is in detail explained on the URL.

In short it comes down to this: Selectboxes get a decimal width in pixels. The returned width in Firebug and jQuery is always the floor of the value, while the actual rendered width can be more 

Reproducible: Always

Steps to Reproduce:
See http://www.sjonner.nl/sites/half-pixel/
Actual Results:  
The rendered width is larger than the value shown in firebug of required with jQuery .width() method.

Expected Results:  
The actual width should be equal to the calculated width.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> In short it comes down to this: Selectboxes get a decimal width in pixels.

Sure.  That can happen pretty easily.  Letters don't have integer pixel widths, so when you measure the width of some text it's typically not an integer number of pixels.

> The returned width in Firebug and jQuery is always the floor of the value

Sounds like bugs in Firebug and jQuery.  You can use getBoundingClientRect to get a correct width if you want.  It's sad that jQuery is not doing that.

> The actual width should be equal to the calculated width.

Well, yes, if you calculate the width correctly.  Which jQuery is clearly failing to do, based on your testcase.  Please file a bug on them!

Comment 2

[John van Keulen]

Thanks for your answer Boris, but partially disagree. Even if we let Firebug, jQuery, or any tool for that matter, out of the problem, FF4 RC2 renders the box a certain number of pixels, but uses a different value for positioning subsequent elements.

Let met elaborate a bit further on the problem, specificly the behavior of FF4, and not on the tools which allowed me to find the problem (They just return the width of the _actually rendered width. Whether or not that is desired, is a different discussion, but I think the value that's returned is the only useful value for web developers):

If counting/measuring the width of the rendered select elements in an image editor, you can see it has a certain width (in my case 159 px). Do this for all elements and we see that when floated left, all elements should fit next to each other. However, the last element is pushed down.

For the record, all versions of previous Firefox handle this scenario correctly.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> but uses a different value for positioning subsequent elements.

John, that's not the case.

> They just return the width of the _actually rendered width

No.  They return the actual rendered width _rounded_ to integer pixels.  The actual rendered width is not an integer number of pixels.

> If counting/measuring the width of the rendered select elements in an image
> editor, you can see it has a certain width (in my case 159 px).

No, it doesn't.  It has a non-integer width, with antialiasing around the edges to get it onto the pixel grid.  But the non-integer width is what's used for all the layout calculations _internally_.  Your script, however, uses _rounded_ values to compute widths, and the rounding loses information, so your script sets incorrect widths.  The solution is to get actual rendered widths, not rounded ones, in your calculations.

> For the record, all versions of previous Firefox handle this scenario
> correctly.

When using GDI, which previous versions of Firefox on Windows did, fonts are snapped to the pixel grid, so text is always integer-width and this situation does not arise.  With DirectWrite, it can arise.  

On other platforms, where the system font renderer has been decent all along, we've had subpixel text rendering for a good long while.  I see identical behavior, with the green button wrapped to the next line, on your testcase in Firefox 4, 3.6, 3.5, and 3.0 on Mac, for example.

This is really a problem in how you're measuring the width of the select.  Do try using getBoundingClientRect for the purpose.

Comment 4

[John van Keulen]

Thanks for the clear answer!

I did not know it was possible for the browser to draw to parts of a pixel. I thought elements and text always snapped to the pixel grid. :)

Thanks for your time.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Well, in some browsers they do (e.g. in WebKit-based ones).  That is, until you zoom... ;)