Skip to main content

Bug Tracker

Side navigation

#14318 closed bug (fixed)

Opened August 29, 2013 10:01PM UTC

Closed August 30, 2013 04:41PM UTC

Last modified September 20, 2013 12:15AM UTC

The animations fadeIn and fadeOut do to function as expected when used with stop()

Reported by: Owned by:
Priority: low Milestone: 1.11
Component: effects Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:

Before I start, I'll mention tickets I've found that appear related. When I first began the search I found: This issue is semi related as it effects the behavior of calling an animation (in this case fadeOut()) and then stopping the transition later and calling another animation (in this case fadeIn()). Unfortunately while this ticket resolved the slideUp/slidDown behaviors fadeIn/fadeOut still don't function as expected.

It appears this report is a duplicate of but that was closed as not a bug; however, in what way would the intended flow of slideUp().stop().slideDown().stop().slideUp() be different if the animation was changed? It only makes sense that calling stop().fadeIn() on a element currently fading out would completely stop the fadeOut and perform a fade in as expected, not halt the animation all together and leave an semi-opaque element on the page (I don't know when, if ever, that would be useful).

The issue is with fadeIn being called after a stop(true) on an element that is fading out. This issue has cropped up with tooltips and anytime a tooltip is fading out and .stop(true).fadeIn() is called on it it stops the fadeOut but never performs the fadeIn leaving a semi-opaque tooltip floating on the page (most of the time illegible). The demo I've provided isn't tooltips but if you press the button twice (rapidly) you can see that the fade in is never performed despite it being called. If you press the button again after "freezing" the animation the appropriate action will take place.

I've rigged a demonstration here:

Some notes: I've tested this in Chrome 29.0.1547.57, Firefox 23.0.1 and Safari 6.0.5 and the issue occurs the same in all of them.

I found the issue with jQuery version 1.10.2 (default packaged with Rails) but have tested it via JSFiddle with 1.10.1 and 1.x.edge (which is 1.10.3 as of this posting). The issue also occurred in 1.9.1 which contained the fix for stop and slideUp/slideDown.

I've tested the sample in jQuery 2+ and the animation works exactly as expected (which also leads me to believe this is really a bug with 1.10.2 unlike remarked by the second ticket I mention).

Attachments (0)
Change History (5)

Changed August 30, 2013 12:46AM UTC by gibson042 comment:1

status: newopen

At a glance, it looks like some master effects commits didn't get cherry-picked into 1.x-master. Finding them is gonna be fun.

Changed August 30, 2013 04:41PM UTC by Richard Gibson comment:2

resolution: → fixed
status: openclosed

Fix #14318: Cherry-pick interrupted animation fix from master ea5c22ec12e6a548b1ec2d7b0dcd9f71bea8d5dd

Changeset: 83396ba832e1169c2e82ceb8493427e5456a82e9

Changed September 20, 2013 12:09AM UTC by dmethvin comment:3

milestone: None2.1

Changed September 20, 2013 12:13AM UTC by dmethvin comment:4

milestone: 2.11.11

Changed September 20, 2013 12:15AM UTC by dmethvin comment:5

component: unfiledeffects
priority: undecidedlow