Opened 11 years ago
Closed 9 years ago
#10462 closed bug (notabug)
animate with stop calls in succession react synchronously to asynchronous actions
| Reported by: | timmywil | Owned by: | fracmak2 |
|---|---|---|---|
| Priority: | low | Milestone: | 1.next |
| Component: | effects | Version: | 1.6.4 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
calling .stop().fadeIn().stop().fadeOut().stop().fadeIn() does not lead to a fadeIn
Change History (6)
comment:1 Changed 11 years ago by
| Component: | unfiled → effects |
|---|---|
| Milestone: | None → 1.next |
| Priority: | undecided → low |
| Status: | new → open |
comment:2 Changed 10 years ago by
| Owner: | set to fracmak2 |
|---|---|
| Status: | open → assigned |
comment:3 Changed 10 years ago by
comment:4 Changed 10 years ago by
The underlying issue has to do with an isHidden() call within animate. When an element is set to display: block, and opacity: 0;, the isHidden() call returns false, so fadeIn() calls resolve immediately because it believes it is done.
I've boiled down the test to a new jsfiddle that more accurately represents the issue.
http://jsfiddle.net/fracmak/4WhBL/24/
By calling stop(true), the state of the element is set into a partially visible state according to the animate function because display is set to block, but opacity never gets changed off of 0.
comment:5 Changed 10 years ago by
On a side note, fadeTo probably shouldn't be mixed with fadeIn/fadeOut because the fadeTo(1000, 0).fadeIn(1000) doesn't work
comment:6 Changed 9 years ago by
| Resolution: | → notabug |
|---|---|
| Status: | assigned → closed |
This just seems a result of fade{In,Out} monkeying with the display property as part of their action and not using goToEnd. So although it's unfortunate I don't think it's wrong. If someone wants to propose a solution, great.
#11987 is a duplicate of this ticket.