New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ticket 7067 - Bounce and Pulsate durations are not accurate #168
Conversation
…ke 1000 ms - Fixes #7067 - Also making sure the queued animations run DIRECTLY after the effect
… instead of callbacks can help us see if we have places where we destroyed the queue
}); | ||
$(this).addClass("current") | ||
// delaying the initial animation makes sure that the queue stays in tact | ||
.delay( 10 ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this delay necessary? Shouldn't the queue stay in tact regardless? If there's different behavior when there's already a queue of animations, then that seems like a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright, if the delay isn't there, the hide
animation runs immediately, therefore queuing its animations in the correct location, then the second delay happens, and then the show
happens, also queueing animations correctly. So - The effects SEEM to happen correctly...
Before I fixed the bug in bounce/pulsate with moving the queue back in place... IF we add the delay this is what happens:
queue delay, queue hide, queue delay, queue show, execute hide which QUEUES (at the end) the effect, execute DELAY, execute SHOW which queues more animations (at the end), execute animations....
I added the delay in the test to ensure that we weren't HIDING the fact that the queue is being executed in the wrong order if you use the queue from within the effect...
…s in core will ALWAYS set a duration, no need to default here
Tossed a few more cleanups at this pull request, got rid of some magical boolean math. I tried a few approaches to queueing these animations in the correct location, but nothing seemed to want to work as cleanly as the queue splicing... We can't use any queue other than |
The distance of the bounces changed with this commit. The element used to bounce higher. |
The first pulse in the pulsate effect is too fast. |
Fixed the pulsate effect by switching the default mode to "effect" (its only not specified when you use the .effect() method...) Bounce distances got normalized because they used to be different for hide vs show, that is the reason for that change... |
…cing box - thx @scott_gonzalez for catching this
… has an extra 'half' time as opposed to removing a 'half' time
They also didn't respect the "queue" order - if other animations were queued after the effect, they would run first.
http://bugs.jqueryui.com/ticket/7067