Bug Tracker

Opened 14 years ago

Closed 12 years ago

Last modified 11 years ago

#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:


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"
  1. click the link "height" while having a firebug console open. Notice the height is correct.
  1. click on "Gender" to collapse it. Clicke in "height" again. Notice the height is incorrect.
  1. click on "Gender" to expand it. Notice the animation jump.
  1. (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...
  1. (optional) watch my screencast...


  1. To return the same height() whether it's visible or not.
  1. To return the proper height() when it's not visible.
  1. To not make the animation jump.

Attachments (2)

height-bug.rar (32.0 KB) - added by nachokb 14 years ago.
Little example showing the bug
bug.avi (108.4 KB) - added by nachokb 14 years ago.
quick version of screencast (size constraints)

Download all attachments as: .zip

Change History (8)

Changed 14 years ago by nachokb

Attachment: height-bug.rar added

Little example showing the bug

Changed 14 years ago by nachokb

Attachment: bug.avi added

quick version of screencast (size constraints)

comment:1 Changed 14 years ago by 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
  1. visibility: hidden: so it's not shown when computing
  1. 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:2 Changed 14 years ago by nachokb

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

comment:3 Changed 13 years ago by 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.

comment:4 Changed 12 years ago by 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/

comment:5 Changed 12 years ago by SlexAxton

Milestone: 1.5
Priority: majorlow
Status: newopen

Test case checks out. Adding to the list.

comment:6 Changed 12 years ago by john

Resolution: worksforme
Status: openclosed

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

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

Note: See TracTickets for help on using tickets.