jQuery.ajax: when aborting XMLHttpRequest, error and complete handlers are not being called

[Evolver]

jQuery.ajax: when aborting XMLHttpRequest, error and complete handlers are not being called.

When using asynchronous requests with jQuery.ajax, if there is need to abort already started request from XMLHttpRequest object, the error and complete handlers are not being called, therefore request abortion does not complete gracefully.

For example, consider the following code:

var xhr =jQuery.ajax({

async: true, ..., error: function() {alert('error');}, complete: function() {alert('complete');}

});

xhr.abort(); i expect here the error and complete handlers to be executed.

After some investigating i have found out that jQuery.ajax simply does not fire these events on abortion, plus, jQuery.ajax uses internal 'polling' method to gather status of request for onreadystatechage. The 'polling' method, even if i patch the onreadystatechange func to correctly process state 0 (abort) and fire error and complete events, does not guarantee, that when calling xhr.abort() the callbacks for error and complete events will be executed synchronously to the caller of xhr.abort(), thus, actual error and complete handlers are being executed after xhr.abort(), leading to inconsistency of code.

I have attached a patch that addresses both problems. The patch adds new option to jQuery.ajax function - requestPolling (boolean), to tell ajax whether to use 'polling' or directly attach onreadystatechange function to XMLHttpRequest object. If requestPolling is set to true, xhr.abort() ensures that error and complete callbacks will be executed consistently with xhr.abort(), and control to your code will be passed after both callbacks are executed.

[Evolver]

Patch to correctly handle XMLHttpRequest.abort from jQuery.ajax

[jbdemonte]

Few line under your patch, there is :

if ( isTimeout ){

xhr.abort();

}

I think it may be patched too as :

if ( isTimeout === "timeout"){

xhr.abort();

}

[Evolver]

Yep, they have that typo there. Actually, whole readystatechange code is a bit messy, needs a cleaner rewrite...

[jbdemonte]

Do you know why the value "13" ms is used to loop to check the ready state, why not 12 or 11 ???

[Evolver]

It's like friday, 13. I guess that was the date when that number was picked :)

[dmethvin]

It does call the handlers with the current version.