step and progress callbacks should fire for the last frame, before complete

[[email protected]…]

Consider the following:

$('#target').animate({

height: 200

}, {

duration: 150, easing: 'easeInOutSine', /*queue: false,*/ step: function () {

$('#console').append('step: ' + $('#target').height() + "\n");

}, complete: function () {

$('#console').append('complete: ' + $('#target').height() + "\n");

}

});

I expect step to be called back on every value change, however this often isn't true for the final callback, especially when the duration is short. Sometimes it does work.

​http://jsfiddle.net/ianbytchek/N5DYg/

[dmethvin]

Can you be more specific about what you expect and what you actually see? What do you mean by the "final callback"? The complete callback seems to fire reliably, and the demo seems to work as I would expect.

[anonymous]

When I run the jsfiddle above, I see the following output: step: 0 step: 0 step: 12 step: 27 step: 41 step: 57 step: 83 step: 190 step: 199 complete: 200

I'd expect to see the same value in the last call of step as in the complete callback. There should be one last call of step right before complete, to ensure that the final animation value is ever set in the steps.

[trac-o-bot]

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

[dmethvin]

Closed because "anonymous" answered it in the pending state.

Seems reasonable to have the step function reliably get the final value, we should be able to do that by calling it from the complete function perhaps?

[scottgonzalez]

I still haven't heard any use cases provided, just "I thought this would happen and it didn't." I'm not sure why we'd change our semantics without a valid use case.

[ianbytchek]

Maybe because our "semantics" isn't valid? Whatever it means… Saying this as a question I'd ask myself if someone sent me a ticket.

Use case: You run main animation and something else depends on it's progress. Maybe it fires another animation every 10% of it's progresses. Maybe it does something else.

When that progress is not working as expected it's becomes difficult to depend on it and you'd start using extra functionality and writing extra code making everything bigger and more complex.

[scottgonzalez]

I'm really not sure what you're talking about. Surely you want to know when the animation is fully complete, that's what the complete callback is for. You can't rely on any portion of the animation being captured in the step callback. It's entirely possible that your duration is too small or the window loses focus, or some extremely intensive blocking operation occurs and you get a single step callback and then the animation completes. Or the animation could be stopped. You need to account for this.

Use case: You run main animation and something else depends on it's progress. Maybe it fires another animation every 10% of it's progresses. Maybe it does something else.

These don't sound like use cases. Firing another animation every 10% is going to fail in some scenarios, so you'd need to provide details of an actual example for us to understand why you'd be starting those animations and how you'd handle the various "hiccups."

"Maybe it does something else" is certainly not a use case.

[ianbytchek]

Scott. I'm not going to argue with your points, they are valid, nor explain how to make use of progress in certain situations, because your imagination is short on that.

It makes sense to notify that the progress has hit 100% when animation is complete to avoid using another listener just for that separately (if you are already using the other one for something else).

[gnarf]

This is definitely legit, and here is the use case:

​http://jsbin.com/odocid/2222/edit

This demo I've used in a few talks is actually not painting the last "frame" of each animation. However since everything is random, and it immediately starts the next animation, I've never noticed it.

I'll see if I can tackle this.

[scottgonzalez]

Thanks for providing an actual use case where this would make a difference and not require an explicit check for completeness inside the step callback.

[anonymous]

Sorry for answering late. I often use it for something like this: ​http://jsfiddle.net/f8S3B/2/

[gnarf]

This is actually working as intended.

The "step" callback happens >before< the value is set, where the "progress" callback happens >after< the value is set.

​http://jsfiddle.net/N5DYg/4/

Also, the first argument to the step function is the value that will be set: ​http://jsfiddle.net/N5DYg/5/

Closing this as notabug