Bug Tracker

Opened 10 years ago

Closed 9 years ago

Last modified 8 years ago

#6440 closed bug (invalid)

complete() not called with ajax request

Reported by: danielsomerfield Owned by:
Priority: undecided Milestone: 1.4.3
Component: ajax Version: 1.4.2
Keywords: Cc:
Blocked by: Blocking:

Description

Using the $.ajax() function, I am making a call to code which returns a 302 status code. When I hit the given url via a POST, none of the callbacks are triggered. I have call backs for complete, success and error, and the whole thing wrapped in a try catch just to be sure. It just silently succeeds (so to speak) without calling a single callback. I have even added a global complete--also not called.

There are two ways I can make the callbacks work: use jquery 1.3.2--then it works fine, or step through it with firebug. I step through it, it works fine.

Sadly, due the strange nature of the bug, I don't have a good repro. My simple test cases doesn't repro--I will continue to search for one.

My call is triggered by a button click and looks like this: $.ajax({

url: "url_to_servlet" type: "post", data: {

name: "name", url: "url", onClickAction: "action"

}, success: function(data, status, request) {

alert("success"); NEVER CALLED

}, error: function() {

alert("error"); NEVER CALLED

}, complete: function() {

alert("complete"); NEVER CALLED

}

});

Also: this is under FF3.6 on OS X 10.5.8. Works like a charm on Safari.

The best I can do for right now for a repro is put the code up somewhere on a test server.

Change History (5)

comment:1 Changed 10 years ago by dmethvin

Your servlet is on the same domain as the requesting page, right?

A 302 should be seen as a "success" and call the success/complete handlers.

I don't have a Mac to test with, but could you make a simple change to a copy of jQuery and see if it makes a difference? In jQuery 1.4.2 on line 5323 you'll see this line:

  xhr.status === 304 || xhr.status === 1223 || xhr.status === 0;

try changing it to this (basically replace triple-equals with double):

  xhr.status == 304 || xhr.status == 1223 || xhr.status == 0;

comment:2 Changed 10 years ago by danielsomerfield

Yes it is in the same domain.

Sadly, the change doesn't seem make a difference.

To be clear: in most cases, this usage seems to work fine, but there seems to be some kind of timing issue which is very tricky to reproduce. I have stepped through it and it worked perfectly. I have yet to figure out how that path changes when debugged.

I will try and figure that out.

comment:3 Changed 10 years ago by danielsomerfield

Here's a little more detail: if I put a breakpoint on line 5165--if ( !xhr
xhr.readyState === 0 isTimeout === "abort" )--it works.

It seems that it works because the xhr.readystate == 4. If I do not put a breakpoint in, xhr.readystate == 1, as I could see from logging code.

The operational difference, of course, being that the block starting at 5179 does not run and no callback happens.

Not sure why this is the case, however.

comment:4 Changed 10 years ago by danielsomerfield

I think this might be a firefox 3.6 bug, but I am not 100% sure. It sounds A LOT like http://www.ghastlyfop.com/blog/2007/01/onreadystate-changes-in-firefox.html.

I added the following code and it seemed to work again:

Starting with line 5251

try {

xhr.send( type === "POST"
type === "PUT" type === "DELETE" ? s.data : null );

xhr.onreadystatechange = onreadystatechange; Added as test - DRS

} catch(e) {

jQuery.handleError(s, xhr, null, e); Fire the complete handlers complete();

}

Reregistering the onreadystatechange handler seems to fix it. Not clear why. But it does sound like that old FF bug reference in the blog post.

comment:5 Changed 9 years ago by snover

Priority: undecided
Resolution: invalid
Status: newclosed

I’m marking this bug as invalid due to age. If you are still experiencing this problem, please reopen.

Note: See TracTickets for help on using tickets.