Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
.width(value) sets incorrect width value if block has border and value specified in ems and box-sizing:border-box #1712
Originally reported by tde: http://bugs.jquery.com/ticket/14038
API documentation specifies: "Note that .width("value") sets the content width of the box regardless of the value of the CSS box-sizing property."
There are two key factors leading to this bug
Changed 16 months ago by tde@…
Same behavior with JQuery 2.0.2
comment:2 Changed 16 months ago by dmethvin
Hi, can you convert your example inline here to an example on jsfiddle.net?
comment:3 Changed 16 months ago by m_gol
Owner set to tde@…
Status changed from pending to new
comment:5 follow-up: ↓ 6 Changed 16 months ago by timmywil
Status changed from new to closed
comment:6 in reply to: ↑ 5 Changed 16 months ago by anonymous
Replying to timmywil:
Clearly a bug. You just provided workaround. But If I want block .with('10em) - it should be 10em, not 12em (if border is 1px) and not 14em (if border is 2px) and not 16em (if border is 3px) etc. Open your mind and reconsider this shit. Documentation clearly states - "Note that .width("value") sets the content width of the box regardless of the value of the CSS box-sizing property."
comment:7 Changed 16 months ago by timmywil
Status changed from closed to reopened
comment:8 Changed 16 months ago by timmywil
Owner changed from tde@… to timmywil
So, afaict, there are two routes we can take.
comment:10 Changed 16 months ago by gibson042
I'm in favor of exploring the size and performance impact of option 2, but it may take a while to do so. A stopgap in the meantime might be reasonable, but option 1 seems like overkill.
comment:11 Changed 16 months ago by timmywil
Perhaps we could ensure the units are the same before the setPositiveNumber call. If they're not, set the value as-is.
comment:12 Changed 9 months ago by Joshua Tausz
I discovered a similar case which expands the scope of this bug, using jquery 1.10.2, and Chrome 29, on Windows 7 Enterprise.
This bug occurs with other types of unit miss-match.
In the example provided with the initial report, set a width of 50%, and padding px of 10, and no border. This will result in a width of 70%, very different behavior from expected.
Setting a padding of 2em returns a width of 74%. This which would seem to indicate that 1em is translated to 12px before adding those 12px to the width as 12% each.
I was able to use Chrome's built-in debugger to trace through some of the code.
In file jqery-1.10.js, the function agumentWidthOrHeight, returns -20, to reflect that padding is set to 10px on either side, but there is no unit attached.
Specifically, this occurs on line 7201.
val -= jQuery.css(elem, "padding" + cssExpand [ i ], true, styles);
This is already part of a loop used to add the various values together, so type checking/conversion could be handled inside this existing loop, if the coder were to go with comment:9's option 2.
This value of -20 is used in function setPositiveNumber, under the value "subtract", on line 7179:
Math.max( 0, matches[ 1 ] - ( subtract || 0 ) ) + matches [ 2 ] || "px" )
I suggest using type conversion, and transmitting the type with the value reported from function agumentWidthOrHeight, so that type conversion can be done on or before line 7179.
With the additional style miss-matches, which can cause further issues, I suggest that this is no longer as much of an edge-case.
comment:13 Changed 8 months ago by dmethvin
Milestone changed from 1.11/2.1 to 1.11.1/2.1.1
Milestone changed from 1.11.1/2.1.1 to 1.12/2.2