Skip to main content

Bug Tracker

Side navigation

#12978 closed feature (plugin)

Opened November 28, 2012 01:30PM UTC

Closed November 28, 2012 06:29PM UTC

.stop() does not trigger .fail()

Reported by: ottoln@gmail.com Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.8.3
Keywords: Cc: gnarf
Blocked by: Blocking:
Description

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/

Attachments (0)
Change History (4)

Changed November 28, 2012 04:29PM UTC by gibson042 comment:1

cc: → gnarf
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

Changed November 28, 2012 05:32PM UTC by dmethvin comment:2

_comment0: 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. \ \ http://jsbin.com/ayobuh/12/edit1354124094913681

I agree with gibson042 here. If the first *xxxx* stop()ped animation 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.

http://jsbin.com/ayobuh/12/edit

Changed November 28, 2012 05:49PM UTC by anonymous comment:3

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,

Changed November 28, 2012 06:29PM UTC by gibson042 comment:4

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.