Skip to main content

Bug Tracker

Side navigation

#14634 closed bug (notabug)

Opened December 13, 2013 11:29AM UTC

Closed March 16, 2014 04:40PM UTC

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

Reported by: ianbytchek@gmail.com Owned by: gnarf
Priority: low Milestone: 1.11.1/2.1.1
Component: effects Version: 1.8.0
Keywords: Cc:
Blocked by: Blocking:
Description

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/

Attachments (0)
Change History (14)

Changed December 23, 2013 04:17PM UTC by dmethvin comment:1

owner: → ianbytchek@gmail.com
status: newpending

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.

Changed January 05, 2014 08:19PM UTC by anonymous comment:2

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.

Changed January 20, 2014 08:38AM UTC by trac-o-bot comment:3

resolution: → invalid
status: pendingclosed

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!

Changed January 20, 2014 02:26PM UTC by dmethvin comment:4

resolution: invalid
status: closedreopened

Changed January 20, 2014 02:28PM UTC by dmethvin comment:5

component: unfiledeffects
priority: undecidedlow
status: reopenedopen

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?

Changed January 20, 2014 03:44PM UTC by scottgonzalez comment:6

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.

Changed January 20, 2014 03:58PM UTC by ianbytchek comment:7

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.

Changed January 20, 2014 04:08PM UTC by scottgonzalez comment:8

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.

Changed January 20, 2014 04:15PM UTC by ianbytchek comment:9

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

Changed January 20, 2014 05:00PM UTC by gnarf comment:10

owner: ianbytchek@gmail.comgnarf
status: openassigned
summary: Animations sometimes don't fire the last step eventstep and progress callbacks should fire for the last frame, before complete
version: 1.10.21.8.0

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.

Changed January 20, 2014 05:07PM UTC by scottgonzalez comment:11

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.

Changed January 21, 2014 09:35AM UTC by anonymous comment:12

Sorry for answering late. I often use it for something like this:

http://jsfiddle.net/f8S3B/2/

Changed March 04, 2014 02:51PM UTC by dmethvin comment:13

milestone: None1.11.1/2.1.1

Changed March 16, 2014 04:40PM UTC by gnarf comment:14

resolution: → notabug
status: assignedclosed

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