Ajax.Request (on FF) fires onSuccess when server is down

[jwestbrook]

previous lighthouse ticket #437 by mirko

---

hi all.

try this: - play with a local server (apache?) - create a simple page with an element attached (onclick) with the function below - click the element and all goes well: both FireFox and IE fires the onSuccess event with the alert "onSuccess (status: 200)" and then the onComplete event - stop the server (put it offline) - click the element again: now IE fires the onFailure event and then the on Complete (that is, i think, correct), FireFox still fires the onSuccess event (status: 0 !) and then the onComplete event

eventOnClick = function() {
    new Ajax.Request(this.location.href, {
        method: "post",
        onSuccess: function(transport) {
            alert("onSuccess (status: " + transport.status + ")");
            if (transport.status == 0) {
                try {
                    // try to fire correct event
                //  transport.request.options.onFailure(transport);
                } catch (e) {}
                return;
            }
            // do something useful...
        },
        onFailure: function(transport) {
            alert("onFailure");
            // something went wrong
        },
        onComplete: function(transport) { alert("onComplete"); }
    });
}

in my opinion this is a bug of FF (version 3.0.3 on win) implementation of XMLHttpRequest, not a Prototype issue, but my solution for this is to check the transport status (200 = ok) before call the onSuccess callback. try to uncomment the row into the try-catch and now FF goes right like IE. but i love FF! :-) i discovered this issue writing a long-polling ajax component for php playing with timeouts and simulating connection problems.

thanks for your work

mirko.it

[jwestbrook]

Sergiu Dumitriu March 15th, 2010 @ 03:38 AM

Automatically assuming that a response status of 0 is a failure is not a good solution, since Opera transforms a (successful) 204 status code into 0. These are incompatible browser bugs, and there's little that can be done in a custom javascript.

[jwestbrook]

Taloncor May 14th, 2010 @ 04:01 PM

Calling transport.abort() on any Ajax.Request will also trigger onSuccess with status 0 in Firefox (FF. 3.6.3 in this case)

        var request = new Ajax.Request("long_running.cgi", {
            onSuccess: function(response){
                    alert("onSuccess. Status:"+response.status);
                },
            onFailure: function(response){
                    alert("onFailure. Status:"+response.status);
                },
            });
        request.transport.abort();

[jwestbrook]

Andrew Dupont October 17th, 2010 @ 08:23 AM

I have no idea what to do about this one, as it's much like Sergiu said. Moving this to the next milestone in the hope that someone will discover a miraculous heuristic that can tell successful zeros from unsuccessful zeros.

[jwestbrook]

Nathan Trevivian June 18th, 2012 @ 06:02 PM

Raised https://prototype.lighthouseapp.com/projects/8886/tickets/1358-false-positive-returned-from-ajaxrequestsuccess-function which seems to be a duplicate of this. Is there anyway of wrapping transport so that abort must always be called on the Ajax.Request object? Then you could track whether the code aborted it, or whether the target was not communicating. Is that bad form? Could then associate with an onAborted handler function...

[jwestbrook]

Nathan Trevivian June 19th, 2012 @ 12:48 PM

The XHR could, of course, be aborted if it hasn't finished and the page is reloaded, so there would also have to be a document unloaded listener to check for these types of abortions as well.

[agustindidiego]

Hi, about this issue. I'm currently running into this when using Ajax.Updater. I tested the issue in FF, Safari and Chrome, and on all browsers I'm getting a status = 0 with an onSuccess call when aborting the request. And I believe that in the case of the Ajax.Updater the issue ends being worst that on Ajax.Request, because the container element is updated to an empty value, and I cannot control the status value and cancel the container update or decide is it should be updated or not.

Cheers.

[solankeyb]

Place the each function as separate block, do not nesting the functions. e.g. you can only define onSuccess function inside onClickEvent(), implementation of onSuccess should be outside.

[savetheclocktower]

Still have no idea what to do about this, but marking it as a bug.

[HeCorr]

I'm having the same issue on Chrome... 7 years later

I had to do this as a workaround:

onSuccess: function (response) {
    if (response.status == 0) {
        return alert("Error: Server not responding");
    }
    // normal code
},