.stop() overrides height/width of element

[apfelbox]

Hello,

I have this code example: ​http://jsfiddle.net/2AcL9/1/

There are 2 boxes, which I want to slideUp() and slideDown().

If you now hit the buttons very fast (and often) and stop afterwards, there are several issues:

Without .stop(): The animation is queued and the box slides up and down without doing anything for several times

With .stop(): The animation stops and slides in the opposite direction (which is the desired behaviour). Unfortunately, if sliding down and hitting the button again, the current height becomes the new total height of the element. This means, that the element will only slide to this point from now on.

With .stop(true, true): The problem of .stop() does not occur anymore, but due to the jump to the end of the animation queue, the elements "pops down" or up which does not look very good.

Maybe there is another way to get my desired behaviour (.stop() without the resetting of the height), and I haven't found it yet. I would be glad, if somebody could point me in the right direction. If there is no other way, I would consider this a bug.

1. Version is "edge" of jsFiddle.
2. Browser: Firefox 6.0.2 (all add-ons are disabled)
3. OS: OS X 10.7.1
4. Step-By-Step instructions: see above.
5. description: see above.

Older versions: this is quite an old issue, so I would guess, that there are a lot of versions, where this behaviour occurs.

Cheers apfelbox

[apfelbox]

The same thing happens when using .fadeIn() and .fadeOut().

[apfelbox]

I know that this is the documented behaviour, but how can one resolve it without hacking too deply in the code? ​http://api.jquery.com/stop/

[Rick Waldron]

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket!

Additionally, be sure to test against the jQuery Edge version to ensure the issue still exists. To get you started, use this boilerplate: ​http://jsfiddle.net/FrKyN/ Open the link and click to "Fork" (in the top menu) to get started.

[apfelbox]

It seems, that this will be fixed in 1.7

​http://blog.jquery.com/2011/09/28/jquery-1-7-beta-1-released/

---

Animation Improvements

Before version 1.7, if you stopped an animation before it completed it could create a situation where the element being animated would never return to its full size; it would essentially be stuck at the height that it was when the animation was stopped. We’ve fixed that by remembering the original dimensions before the animation starts so that they can be used later. This eliminates a major annoyance in using certain animations, particularly toggling ones.

[dmethvin]

Duplicate of #8685.

[josh.gruber@…]

I am still experiencing this bug in both 1.7 and the current Edge, with or without clearing the queue:

​http://jsfiddle.net/F5sTJ/ ​http://jsfiddle.net/F5sTJ/1/

(Tested on current Chrome and Firefox)

[Timmy Willison]

State tracking associated with stop is not triggered unless it is a toggled animation where jQuery must make calculations for the user. There is no indication that the user desires a toggled animation unless we are told that it is a toggled animation (by passing 'toggle' to the animated property or by using any of the jQuery toggle effects methods), in which case we treat stop differently. Otherwise, we'd have to do much more complex calculations to predict whether we need to treat some animation like a toggled animation, and then we'd have bug reports about being wrong in those predictions. Your test case with toggling: ​http://jsfiddle.net/timmywil/F5sTJ/2/

However, we have discovered a separate issue regarding animation toggling and that has been opened here: ​http://bugs.jquery.com/ticket/10848