Skip to main content

Bug Tracker

Side navigation

#9399 closed enhancement (fixed)

Opened May 22, 2011 07:20PM UTC

Closed September 22, 2011 02:59PM UTC

Last modified January 21, 2013 11:13AM UTC

Deprecate jqXHR.success and jqXHR.error

Reported by: jaubourg Owned by: jaubourg
Priority: blocker Milestone: 1.8
Component: ajax Version: 1.6.1
Keywords: 1.7-discuss Cc:
Blocked by: Blocking:

Deprecate jqXHR.success and jqXHR.error and start pushing users into using jqXHR.done and jqXHR.complete is a bit more complicated seeing as Deferred.always is not a direct equivalent to it. Goal is to remove jqXHR.success and jqXHR.error in 1.8.

Attachments (0)
Change History (30)

Changed May 22, 2011 07:27PM UTC by john comment:1

keywords: → 1.7-discuss

Nominating ticket for 1.7 discussion.

Changed May 22, 2011 08:25PM UTC by rwaldron comment:2


Changed May 23, 2011 01:08AM UTC by jaubourg comment:3

+0, I suggests this but I have no firm conviction regarding it... hence why I ask you guys

Changed May 23, 2011 05:11AM UTC by timmywil comment:4


Changed May 24, 2011 12:42AM UTC by timmywil comment:5

component: unfiledajax
priority: undecidedlow
status: newopen

Changed May 24, 2011 10:29PM UTC by dmethvin comment:6

+1, This is a quick deprecation, we shouldn't have added it. But I agree it's a mess to retain it, let's document it immediately but leave it in for a while.

Changed June 03, 2011 02:12PM UTC by john comment:7


Changed June 04, 2011 10:17PM UTC by addyosmani comment:8


Changed June 05, 2011 09:56PM UTC by ajpiano comment:9

-1, Doesn't make sense to me that users should have to use the word "success" if they're using an options object to $.ajax but .done if they're subscribing to the $.ajax Deferred-style. (Same for error/fail)

Changed June 06, 2011 02:53PM UTC by danheberden comment:10

+1, please please please

Changed June 06, 2011 03:45PM UTC by scottgonzalez comment:11

-1, the name success is all over the place for ajax, we should keep these

Changed July 12, 2011 03:08PM UTC by dmethvin comment:12

milestone: 1.next1.7
priority: lowblocker

Changed July 12, 2011 03:10PM UTC by dmethvin comment:13

keywords: 1.7-discussneedsdocs 1.7-discuss

Changed July 13, 2011 05:48AM UTC by addyosmani comment:14

keywords: needsdocs 1.7-discuss1.7-discuss

Changed July 25, 2011 04:21PM UTC by john comment:15

owner: → jaubourg
status: openassigned

Changed September 22, 2011 02:59PM UTC by jaubourg comment:16

resolution: → fixed
status: assignedclosed

This is documented as deprecated already so I'll consider this fixed... unless we wanna keep track of this for removal in 1.8?

Changed October 03, 2011 07:53AM UTC by flipace comment:17

Where can I find information about - why - these got deprecated?

Changed October 03, 2011 07:53AM UTC by flipace comment:18

Where can I find information about - why - these got deprecated?

Changed October 03, 2011 12:29PM UTC by anonymous comment:19

Not only why, but why the documentation examples still use success, error, and complete. Deprecating this is 1.7 and removing in 1.8 doesn't give enough time. These shouldn't be removed until at 1.9 or later. Or at the very least, alias success, error, and complete to done, fail, always for backwards compatibility.

Changed October 14, 2011 01:18PM UTC by anonymous comment:20

Absolutely concur with commentor 18. The success, error,and complete handlers should be aliased for backward compatibility for an extended period, if not indefinitely. I shudder to imagine the number of unhappy users which would be uncovered by their removal.

Changed October 21, 2011 05:29PM UTC by anonymous comment:21


Don't go changing names just because you don't like them.

Changed October 24, 2011 11:56PM UTC by anonymous comment:22

Docs updated?! The page does not even have these new names in main settings list. Some obscure mention in a semi-random place is not enough. To say the truth whole page is rather incomprehensible, so could be you were just following tradition.

Changed October 25, 2011 12:15AM UTC by ajpiano comment:23

That's because the 'settings' options have not and will not change, only the $.ajax().success() $.ajax().error() etc, aliases to done, fail, always, which will be available in 1.7 and deprecated in 1.8. This is a relatively new API anyway (1.5) and keeping these aliases around in perpetuity is unwise.

Changed October 25, 2011 03:34AM UTC by anonymous comment:24

Yay, this will only break ALL MY WEBSITES!

Changed November 01, 2011 06:04PM UTC by comment:25

@ajpiano Is there a roadmap for when the removal of these methods are planned to take place?

Changed November 01, 2011 08:34PM UTC by SlexAxton comment:26

Upon removal, could we release a compatibility plugin to re-alias these for people who don't understand how that would work themselves? Shouldn't be too difficult...

Changed November 01, 2011 08:36PM UTC by dmethvin comment:27

I agree we could do a better job at publicizing the logic behind these changes, and we will in the future.

Note that this change isn't intended to remove any functionality, it just removes the aliases that we put on the Deferred object returned by $.ajax so that it uses the standard Deferred names. It should be possible to move to the new names via a simple text replace in most cases.

@eli, no there is not a roadmap for removal in general. We are deprecating things to indicate that they are not the best-practice way to do something in jQuery. It's possible that things that are deprecated are *never* removed, but then again we are unlikely to add features to it or fix bugs in a feature like that.

success, error,and complete handlers should be aliased for backward compatibility for an extended period, if not indefinitely

Agreed about the extended period. Note, however, that even if we wait five years there will be people who have not changed their code. Deprecation is the start of the notice we need to give if we are ever to have a hope of removing something.

In the meantime, nothing prevents anyone from using the features marked deprecated in 1.7, including this one. We will start a separate (and more visible) thread about the direction of jQuery once 1.7 has shipped.

could we release a compatibility plugin

That has been suggested and would most likely be our approach for many of these things in the 2.0 time frame.

Changed November 30, 2011 10:31PM UTC by anonymous comment:28

I think the document should clearly indicate the $.ajax() option names of success etc are not changed. I got the impression that they may also changed reading the 1.7 docs, and couldn't find clear answers in the doc itself.

Changed June 27, 2012 03:10PM UTC by dmethvin comment:29

milestone: 1.71.8

This deprecation notice is being moved to 1.8, since the docs indicated it was to start then despite this ticket.

The reason these were deprecated is that they create an unneeded special case for the Deferred returned from an XHR.

Changed January 21, 2013 11:13AM UTC by anonymous comment:30

This change does not include the $.get and $.post methods, right?