Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket!

Additionally, be sure to test against the "jQuery (edge)" version to ensure the issue still exists. To get you started, use this boilerplate: http://jsfiddle.net/FrKyN/

Open the link and click to "Fork" (in the top menu) to begin.

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!

I'm seeing this too in 1.7.2. My code is a BBoM and so providing a stripped-down example is challenging.

However, I will add that one of the interesting properties of this bug that I've noticed is that in my specific situation, this works:

$.ajax({success: function(){ /* code runs */ }});

However, this does not:

$.ajax({}).success(function(){ /* code doesn't run */ });

And yet, and this is the oddest part, using a mix of styles will cause *both* to fire (even the one that wasn't previously):

$.ajax({success: function(){ /* code runs */ }}).success(function(){ /* code runs */ });

Some more info:

• my tests have been constrained to IE
• doesn't appear to affect all uses (just specific use-cases)
• the response is very large, taking 20s and almost 4mb in size
• When .success() fails to fire, IE's dev tools shows 200 OK (with the valid response body)
• Also when .success() fails to fire, .done() doesn't fire either.

Figured out the problem and have deduced a valid test case, and it appears to be caused by the [undocumented?] fact by setting a success callback within the ajaxOptions will replace any callbacks previously set via $.ajaxSetup(). However, using xhr.success(fn(){}) to set a callback merely adds to the stack. I couldn't find this distinction on http://api.jquery.com/jQuery.ajax/ but then again, it's a mountain of text and I didn't read anywhere near all of it. Just making a note here for others that may come across this in the future.

In my case, I had forgotten that I had a success callback already set with ajaxSetup(), and an exception generated in that default handler prevented any additional handlers from getting called. This explains why setting a success callback explicitly on the ajaxOptions allowed both to fire -- the original handler which generated the exception was replaced.

Here's a jsfiddle which exhibits the behavior:

http://jsfiddle.net/j5Jtu/2/

And now the counterpart (overriding the default handler which generates the exception):

http://jsfiddle.net/j5Jtu/3/

Repro'd on Chrome 19.

It is not good practice to use $.ajaxOptions since (as you found) that affects things globally including code you didn't write (plugins for example). If your code was throwing an error, did you see that on the console?