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)
Change History (6)
Changed May 20, 2009 02:54AM UTC by comment:1
Changed May 21, 2009 12:59AM UTC by comment:2
You may close the ticket if you consider this not worth fixing.
Changed June 22, 2010 01:54AM UTC by 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 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 comment:5
| milestone: | → 1.5 |
|---|---|
| priority: | major → low |
| status: | new → open |
Test case checks out. Adding to the list.
Changed April 17, 2011 06:35PM UTC by comment:6
| resolution: | → worksforme |
|---|---|
| status: | open → closed |
Setting a width on the element allows it to work just fine.
For example:
I found out what's causing it.
In line #750 (of
) the function is defined.In here, two conditions are met: height is requested and the element is invisible (that's detected with
).So it uses
to temporarily set1.
:so its height can be measured2.
: so it's not shown when computing3.
: so it doesn't reflow other elementsThe 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
changes the semantics of the default (?) 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
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?)