Side navigation
#12373 closed bug (duplicate)
Opened August 22, 2012 01:50PM UTC
Closed December 13, 2012 07:00AM UTC
outerWidth()/outerHeight() may return wrong results in IE with enabled hw rendering
| Reported by: | jquery@freakstuff.de | Owned by: | jquery@freakstuff.de |
|---|---|---|---|
| Priority: | high | Milestone: | None |
| Component: | dimensions | Version: | 1.8.0 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Because IE is using float for internal calculated widths ands heights using outerWidth()/outerHeight() does not always return the correct integer result.
Example:
<div><span>Text portion 1</span><span>Text portion 2</span></div>
$('div').width($('span:first').outerWidth() + $('span:last').outerWidth());
This should set the div to a width so that both span contents can be displayed in one line. But the internal calculated width of the spans can be something like '88.17' or '88.49'. jQuery will return '88' for each.
So the width of the div will be 176. The browser internally needs 176.66 pixels to render both spans. So the correct width will be 177. So the divs width has one pixel missing. The last character will not fit into the container.
Tested in IE 9.0.8112.16421 32 bit on Windows 7. Settings are default. Nothing changed. In firefox and chrome this works fine.
Attachments (0)
Change History (8)
Changed August 22, 2012 01:56PM UTC by comment:1
Changed August 22, 2012 02:29PM UTC by comment:2
| component: | unfiled → dimensions |
|---|---|
| owner: | → jquery@freakstuff.de |
| priority: | undecided → high |
| status: | new → pending |
Thanks for the test case. So is the suggestion here for outerWidth/OuterHeight to return the float instead of an int if it can?
Changed August 23, 2012 06:50AM UTC by comment:3
| _comment0: | I think returning float would be the best for calculations, but it might break current implementations. However, for example using $.('div').width(176.66) must be interpreted correctly. I'm thinking about an internal Math.ceil inside the width function and other functions that are dealing with widths and heights. \ \ I've updated the fiddle: http://jsfiddle.net/y6Dmt/2/ \ I added two input fields, background and animation. In microsofts developer tools inputs have a calculated width and height which is correctly shown. → 1345704799680809 |
|---|
I think returning float would be the best for calculations, but it might break current implementations. However, for example using $.('div').width(176.66) must be interpreted correctly. I'm thinking about an internal Math.ceil when setting a value inside the width function and other functions that are dealing with widths and heights.
I've updated the fiddle: http://jsfiddle.net/y6Dmt/2/
I added two input fields, background and animation. In microsofts developer tools inputs have a calculated width and height which is correctly shown.
Changed September 06, 2012 08:57AM UTC by comment:4
| resolution: | → invalid |
|---|---|
| status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
Changed September 06, 2012 09:38PM UTC by comment:5
Hey, why is this closed? I've answered the only question that had been asked. Please reopen this. The bug does still exist. You can see, that I'm registered with the authors mail adress.
Changed September 09, 2012 03:22AM UTC by comment:6
| resolution: | invalid |
|---|---|
| status: | closed → reopened |
It was autoclosed because you replied with a different username than you submitted the report with. This is confirmed.
Changed September 09, 2012 03:22AM UTC by comment:7
| status: | reopened → open |
|---|
Added a test case on fiddle: http://jsfiddle.net/y6Dmt/1/