Bug Tracker

Opened 11 years ago

Closed 11 years ago

#12978 closed feature (plugin)

.stop() does not trigger .fail()

Reported by: ottoln@… Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.8.3
Keywords: Cc: gnarf
Blocked by: Blocking:


This could be considered a feature, but I consider it a bug.

When an animation is stopped using (true,false) arguments, it should trigger promise().fail(), not promise.done(), since animation did not get carried till the end.

ex: http://jsbin.com/ayobuh/3/

Change History (4)

comment:1 Changed 11 years ago by gibson042

Cc: gnarf added
Status: newopen
Type: bugfeature

Considering that the sets of elements for .stop and .promise are not necessarily identical, much would have to be decided about under which circumstances—and when—to fail a .promise. This could easily get very messy, and I think I'd be against changing the behavior for that reason alone.

Do the new-in-1.8 animation callbacks solve your use case? They're not yet well-documented, but we're working on it (https://github.com/jquery/api.jquery.com/issues/61, https://github.com/jquery/api.jquery.com/issues/81).

I've updated your example to show how you might take advantage of them: http://jsbin.com/ayobuh/10/edit

comment:2 Changed 11 years ago by dmethvin

I agree with gibson042 here. If the first failed promise failed the collection, for example, you wouldn't know when the unfailed animations completed.

We already provide the tools to solve this. The code stopping the animation isn't some remote external force, so it can easily coordinate a signal with other code in the app. For example, to get a failed promise you could join both the animate promise and a second promise that you .reject() in the function where .stop() is called. Wrap it all up in your own method to keep it DRY.


Version 0, edited 11 years ago by dmethvin (next)

comment:3 Changed 11 years ago by anonymous

Thanks for showing me the new syntax. It does deliver what I think is vital: a way to know whether the animation ran till the end with "complete" and "done" or if it got stopped, with "fail". It sounds weird that whatever deferred object is used inside the animate function, is not the same that is passed on the promise object though.

So I still think that promise().done() should be triggered only when animation went till the end, and that promise().fail() should be triggered in that case.

Otherwise, what else could it mean, semantically, right? I think "fail" is closer to stopped then "done".

Thanks once again from sunny Brazil,

comment:4 Changed 11 years ago by gibson042

Resolution: plugin
Status: openclosed

The problem is that .promise doesn't cover the animation; it covers all pending actions in a single queue for all elements in the jQuery collection. Semantically, resolution of the promise indicates that those actions are no longer pending, and it's not clear to me how we could provide a meaningful rejection.

The promises for a particular animation (that resolve/reject in the way you expect) are passed as the first argument to .animate callbacks, including start.

I don't see a way for .promise to satisfy this ticket without breaking existing code, but @dmethvin's example could be generalized into a plugin.

Note: See TracTickets for help on using tickets.