#4666 closed bug (worksforme)
height() is incorrectly computed
Reported by: | nachokb | Owned by: | brandon |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | dimensions | Version: | 1.3.2 |
Keywords: | animation jump height dimensions | Cc: | [email protected]… |
Blocked by: | Blocking: |
Description
I have a case in which .height() is being incorrectly computed, so a slide animation jumps.
The particular conditions in which this is reproduced involves a div with a few input & label elements, having the input be floated left... I attach an example (I tried to strip it to the bare minimum). I also attach a screencast with the bug explained...
I tried to debug jQuery but couldn't (Firebug died on me)
Steps to reproduce:
- unrar the attached example, "height-bug.html"
- click the link "height" while having a firebug console open. Notice the height is correct.
- click on "Gender" to collapse it. Clicke in "height" again. Notice the height is incorrect.
- click on "Gender" to expand it. Notice the animation jump.
- (optional) with Firebug, try to disable "float: left" on the <input type="radio"/>. Notice that the real height now is somewhat close to the one incorrectly reported before...
- (optional) watch my screencast...
Expected:
- To return the same height() whether it's visible or not.
- To return the proper height() when it's not visible.
- To not make the animation jump.
Attachments (2)
Change History (8)
Changed 14 years ago by
Attachment: | height-bug.rar added |
---|
comment:1 Changed 14 years ago by
I found out what's causing it.
In line #750 (of jquery-1.3.2.js
) the function css()
is defined.
In here, two conditions are met: height is requested and the element is invisible (that's detected with offsetWidth === 0
).
So it uses jQuery.swap()
to temporarily set
display: block
:so its height can be measured
visibility: hidden
: so it's not shown when computing
position: absolute
: so it doesn't reflow other elements
The problem was that the last property broke elements which (a) had not an explicit width set and (b) changing its width made its content reflow, and possibly change its height (e.g. floats).
This is because position: absolute
changes the semantics of the default (auto
?) width (I think it's 100% with default position, but changes to fit the content when it's absolute).
So the solution in my case was to put width: 100%
in the element being measured.
Perhaps an heuristic could be inferred from this: when height is required and width is not set, set width to 100% before measuring? (someone with better knowledge of CSS semantics here?)
comment:3 Changed 13 years ago by
Actually the analysis here seems correct, and may be at the root of some other reports. I'm just not sure of a solution.
comment:4 Changed 12 years ago by
I've taken your test case and boiled it down to make it much simpler and get more at the essence of the problem. http://jsfiddle.net/boushley/En4Ew/1/
comment:5 Changed 12 years ago by
Milestone: | → 1.5 |
---|---|
Priority: | major → low |
Status: | new → open |
Test case checks out. Adding to the list.
comment:6 Changed 12 years ago by
Resolution: | → worksforme |
---|---|
Status: | open → closed |
Setting a width on the element allows it to work just fine.
For example: http://jsfiddle.net/En4Ew/35/
Little example showing the bug