Bug Tracker

Ticket #3250 (closed bug: wontfix)

Opened 6 years ago

Last modified 6 years ago

ajax success callback inconsistent with error and complete

Reported by: jtate Owned by:
Priority: critical Milestone: 1.3
Component: core Version: 1.2.6
Keywords: Cc:
Blocking: Blocked by:


success's callback takes data and textStatus, whereas the other callbacks take XHR response objects.

This typically is not a problem, however, Javascript passes simple datatypes (like strings) as copies. When working with large datasets, it doesn't take many copies of the data on the stack to overload the Firefox 3 stack management restrictions and exhaust it. The error you get from FF3 is "script stack space quota is exhausted". If the success callback took an XMLHttpResponse object instead of a string, the exposure would be reduced, as objects in Javascript are passed by reference.

To work around this problem, I leave off the success callback, and instead specify a complete callback, in which I test for success.

Change History

comment:1 Changed 6 years ago by nathanhammon

I didn't write it, but the inconsistency there is probably to make things easy for those who don't know what they're doing. Hopefully they don't run into this problem. (Hopefully anyone that does will be able to figure out why they're ending up with it).

One possible resolution is to turn $.ajax() into an "advanced" mode where the success handler is passed the xhr object and the others ($.get, $.post ... the aliases) get passed the data string.

Couldn't be until at least the 1.3 release. Thoughts?

comment:2 Changed 6 years ago by john

  • Status changed from new to closed
  • Resolution set to wontfix

While this is unfortunate in your case - I do believe that the API should remain the way it is (success is, by far, the most popular callback and users need simple access to the response - which is what it provides).

comment:3 Changed 6 years ago by jtate

Please note I was not advocating changing the api for the success callback per say. I think it's great for the small data set case. What I'd like to see however is an advanced_success callback (perhaps with a better name) that is called in the same circumstances (defined before or after the standard "success" call) that would take a set of arguments similar to the error and complete callbacks. This is not critical, as I indicated when I filed the bug, as the "complete" callback lets me define my own success handle.

Note: See TracTickets for help on using tickets.