Ticket #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: | ||
| Blocking: | Blocked by: |
Description
calling .stop().fadeIn().stop().fadeOut().stop().fadeIn() does not lead to a fadeIn
Change History
comment:1 Changed 20 months ago by timmywil
- Priority changed from undecided to low
- Status changed from new to open
- Component changed from unfiled to effects
- Milestone changed from None to 1.next
comment:2 Changed 7 months ago by dmethvin
- Owner set to fracmak2
- Status changed from open to assigned
comment:4 Changed 7 months ago by fracmak2
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 7 months ago by fracmak2
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 4 months ago by dmethvin
- Status changed from assigned to closed
- Resolution set to notabug
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.
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.