Skip to main content

Bug Tracker

Side navigation

#4666 closed bug (worksforme)

Opened May 18, 2009 06:10AM UTC

Closed April 17, 2011 06:35PM UTC

Last modified March 15, 2012 02:24PM UTC

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: nachokb@gmail.com
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:

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.

Attachments (2)
  • bug.avi (108.4 KB) - added by nachokb May 18, 2009 06:31AM UTC.

    quick version of screencast (size constraints)

  • height-bug.rar (32.0 KB) - added by nachokb May 18, 2009 06:11AM UTC.

    Little example showing the bug

Change History (6)

Changed May 20, 2009 02:54AM UTC by nachokb comment:1

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

Changed May 21, 2009 12:59AM UTC by nachokb comment:2

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

Changed June 22, 2010 01:54AM UTC by dmethvin comment:3

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

Changed November 03, 2010 09:31PM UTC by boushley comment:4

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/

Changed November 03, 2010 09:34PM UTC by SlexAxton comment:5

milestone: → 1.5
priority: majorlow
status: newopen

Test case checks out. Adding to the list.

Changed April 17, 2011 06:35PM UTC by john comment:6

resolution: → worksforme
status: openclosed

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

For example:

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