Side navigation
#10263 closed bug (duplicate)
Opened September 13, 2011 04:33PM UTC
Closed October 07, 2011 12:44AM UTC
Last modified October 15, 2012 09:02PM UTC
.stop() overrides height/width of element
| Reported by: | apfelbox | Owned by: | apfelbox |
|---|---|---|---|
| Priority: | low | Milestone: | None |
| Component: | effects | Version: | 1.6.4rc1 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Hello,
I have this code example:
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
Attachments (0)
Change History (11)
Changed September 13, 2011 04:36PM UTC by comment:1
Changed September 13, 2011 04:38PM UTC by comment:2
I know that this is the documented behaviour, but how can one resolve it without hacking too deply in the code?
Changed September 19, 2011 04:10PM UTC by comment:3
| owner: | → apfelbox |
|---|---|
| status: | new → pending |
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.
Changed September 19, 2011 04:15PM UTC by comment:4
| component: | unfiled → effects |
|---|---|
| priority: | undecided → low |
Changed September 30, 2011 02:51PM UTC by comment:5
| status: | pending → new |
|---|
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.
Changed October 07, 2011 12:44AM UTC by comment:6
| resolution: | → duplicate |
|---|---|
| status: | new → closed |
Changed November 21, 2011 07:30PM UTC by comment:8
I am still experiencing this bug in both 1.7 and the current Edge, with or without clearing the queue:
(Tested on current Chrome and Firefox)
Changed November 21, 2011 08:45PM UTC by comment:9
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:
Changed November 21, 2011 08:59PM UTC by comment:10
| keywords: | → needsdocs |
|---|
Changed October 15, 2012 09:02PM UTC by comment:11
| keywords: | needsdocs |
|---|
The same thing happens when using .fadeIn() and .fadeOut().