Skip to main content

Bug Tracker

Side navigation

#10015 closed bug (duplicate)

Opened August 10, 2011 06:33PM UTC

Closed August 12, 2011 03:48PM UTC

Last modified March 10, 2012 02:10AM UTC

.slide*() and .stop()

Reported by: Owned by:
Priority: low Milestone: None
Component: effects Version: 1.6.2
Keywords: Cc: timmywil
Blocked by: Blocking:
Description - Don't know how long it will stay up, but here's a demonstration of the bug, and the associated source code.

Okay, so here's the deal. .stop(true,false) stops the animation in progress and clears the queue. For most animations, this works fine. However, in the instance of .slideUp(), .slideDown(), and .slideToggle(), it also has an interesting effect on elements whose heights are defined by the content they contain (a necessity for dynamic content). Running the animation again will not fully-show the element's height, but will instead return it to the height at which it was .stop()'d. This can leave a significant portion of the element's content hidden.

For posterity's sake (in case the jsfiddle link doesn't work, or you can't use it or whatnot), here's some code:

<!DOCTYPE html>



<meta http-equiv="content-type" content="text/html; charset=UTF-8">

<title> - jsFiddle demo</title>

<script type='text/javascript' src=''></script>

<script type="text/javascript" src=""></script>

<style type='text/css'>




border:1px #000;







a {





<script type='text/javascript'>


$(document).ready(function() {

<!-- Yes, this whole thing could be accomplished by .slideToggle(). But the problem persists that way, too! -->

$("#clicker a").click(function() {

if ($("#clickee").hasClass('clicked')) {

$("#clickee").stop(true, false).slideUp("slow", 'easeInOutCubic').removeClass('clicked');

} else {

$("#clickee").stop(true, false).slideDown("slow", 'easeInOutCubic').addClass('clicked');



$("#clicker2 a").click(function() {

if ($("#clickee2").hasClass('clicked')) {

$("#clickee2").stop(true, false).animate({

height: 'hide'

}, 500, 'easeInOutCubic').removeClass('clicked');

} else {

$("#clickee2").stop(true, false).animate({

height: 'show'

}, 500, 'easeInOutCubic').addClass('clicked');








<div id="clicker"><a href="#">Click me! :D</a></div>

<div id="clickee" style="display:none;">This Div's height is defined by its content. There is no other definition for this div's height. Animation should allow it to go all the way down to the end of the world, but that's why I'm posting a bug report.</div><br />

<br />

<br />

<div id="clicker2"><a href="#">Click me more! >8D</a></div>

<div id="clickee2" style="display:none;">This is the second Div. Like the first, the text is the only thing that defines its height. The animation, like the first, defines the height, and when interrupted, still causes problems.</div>



Also note that one of the experts in the IRC channel (Brodingo) was able to create a work-around (using .animate() with variables and {queue:false}; I'll post the code he wrote at the end), but it seems like something that could stand to be fixed in an upcoming release of jQuery.



((Brodingo's Workaround Code:

$(document).ready(function() {

var toggleHeight = $("#clickee").height();


$("#clicker a").toggle(function(){

$("#clickee").animate({height: toggleHeight, paddingTop:".5em", paddingBottom:".5em"},{queue:false});

}, function(){

$("#clickee").animate({height: 0, paddingTop:0, paddingBottom:0},{queue:false});




Attachments (0)
Change History (5)

Changed August 10, 2011 07:17PM UTC by ajpiano comment:1

cc: → timmywil
component: unfiledeffects

I have a feeling this may be a dupe of #8685, but I can't quite tell if the problem you're experiencing here is remedied completely by the current work on the jQuery (edge) branch, which I've tested against here - or if the error is at least partially due to the timing of when you're adding the classes to toggle the slide direction versus when those slide animations are actually complete. I think the goal of #8685 is to remedy these symptoms, however, so I'll kick it to Timmy for a bit more insight.

Changed August 10, 2011 07:48PM UTC by comment:2

That correlation wouldn't surprise me one bit. I wish I could be more helpful in providing a solution, but I'm just learning jQuery here (never could quite get my head around JavaScript back in the day). As to the class toggling, I made a page that should wait until after the animations are complete to add the class: even stranger results in this one (tested in Chrome's latest release as of this post time, don't have other browsers on this machine):

By putting the class assignment in the callback, it ''should'' only apply that after the animation has run, correct? Putting the class assignment before the stop and the animation doesn't change the results at all:

For now I guess Brodingo's work-around is the code of choice, at least until the problem is resolved, because the jQuery (edge) doesn't seem to remedy the problem (at least on Chrome, but this is for a project that requires functionality on all browsers, and with some studies putting Chrome at a 30% market share...yeah).

Changed August 12, 2011 02:56PM UTC by dmethvin comment:3

To recap: When you stop the animation and don't use gotoEnd it's leaving the explicitly set height on the element. At the moment there isn't any way for subsequent animations to know this was left behind by a stop()ped animation and should be ignored in favor of the auto height. A comment by rpflorence over on #8685 describes one possible solution that sounds like it would work.

Changed August 12, 2011 03:48PM UTC by timmywil comment:4

priority: undecidedlow
resolution: → duplicate
status: newclosed

Sorry I didn't get to this sooner. Yes, this won't be a problem in 1.7 when 8685 has landed so I'll mark this as a dupe. Here are a couple workarounds in the meantime:

Changed August 12, 2011 03:48PM UTC by timmywil comment:5

Duplicate of #8685.