Bug Tracker

Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#3250 closed bug (wontfix)

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:
Blocked by: Blocking:

Description

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 (3)

comment:1 Changed 15 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 15 years ago by john

Resolution: wontfix
Status: newclosed

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 15 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.