height() is incorrectly computed

[nachokb]

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:

1. unrar the attached example, "height-bug.html"

2. click the link "height" while having a firebug console open. Notice the height is correct.

3. click on "Gender" to collapse it. Clicke in "height" again. Notice the height is incorrect.

4. click on "Gender" to expand it. Notice the animation jump.

5. (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...

6. (optional) watch my screencast...

Expected:

1. To return the same height() whether it's visible or not.

2. To return the proper height() when it's not visible.

3. To not make the animation jump.

[nachokb]

Little example showing the bug

[nachokb]

quick version of screencast (size constraints)

[nachokb]

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

1. display: block:so its height can be measured

2. visibility: hidden: so it's not shown when computing

3. 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?)

[nachokb]

You may close the ticket if you consider this not worth fixing.

[dmethvin]

Actually the analysis here seems correct, and may be at the root of some other reports. I'm just not sure of a solution.

[boushley]

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/

[SlexAxton]

Test case checks out. Adding to the list.

[john]

Setting a width on the element allows it to work just fine.

For example: ​http://jsfiddle.net/En4Ew/35/