Bug Tracker

Ticket #14318 (closed bug: fixed)

Opened 15 months ago

Last modified 14 months ago

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

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

Description

Before I start, I'll mention tickets I've found that appear related. When I first began the search I found: http://bugs.jquery.com/ticket/13483. 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 http://bugs.jquery.com/ticket/10462 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:  http://jsfiddle.net/7GmTx/

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).

Change History

comment:1 Changed 15 months ago by gibson042

  • Status changed from new to open

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.

comment:2 Changed 15 months ago by Richard Gibson

  • Status changed from open to closed
  • Resolution set to fixed

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

Changeset: 83396ba832e1169c2e82ceb8493427e5456a82e9

comment:3 Changed 14 months ago by dmethvin

  • Milestone changed from None to 2.1

comment:4 Changed 14 months ago by dmethvin

  • Milestone changed from 2.1 to 1.11

comment:5 Changed 14 months ago by dmethvin

  • Priority changed from undecided to low
  • Component changed from unfiled to effects
Note: See TracTickets for help on using tickets.