Ariel - any thoughts here?

OK, I have an update from some further testing on this topic.

Contrary to my conjecture originally, I have confirmed that in both cases, flXHR fully returns (that is, gets to readyState=4), with the responseText set as expected.

However, what I've determined is that jQuery has already "aborted" and given up on the request. The tricky part is why -- the reason is that sometimes flXHR doesn't immediately go from readyState 0 to 1 when open() is called -- whenever there is an additional cross-domain policy check that needs to first be performed (which is what happens when the URL's are different, as in my original post). So, basically, there's a race condition created, and jQuery now has logic in it which gets tripped up on this race condition.

The triggering jQuery code difference that causes this "bug" to show up from 1.2.6 to 1.3 is that you now have this bit of code in there:

if (ival) {
	// clear poll interval
	clearInterval(ival);
	ival = null;
	// Handle the global AJAX counter
	if ( s.global && ! --jQuery.active )
		jQuery.event.trigger( "ajaxStop" );
}

Basically, this check gets called quickly enough (after the first 13ms interval wait) that flXHR hasn't yet moved from 0 to 1. So, jQuery thinks the operation has somehow been aborted and so it abandons the request (even though flXHR is still going just fine in the background).

So, bottom line, there is a technical reason why I have flXHR not moving to readyState=1 until the policy check is made (which I can explain if you are interested), but basically it creates now an incompatibility with jQuery's new logic relating to how it tries to determine if an XHR request should be abandoned because it was aborted.

Firstly, I will retract my previous assertion this is purely a jQuery bug. Clearly it's not a "bug" but just an incompatibility between flXHR's implementation of 'XHR' and jQuery's interpretation/recognition of how the native browser XHR works.

So, this all having been diagnosed, I will ask this for your consideration on how (and if) to proceed... Is jQuery's logic as described here fully appropriate (basically to assume a '0' at this point in code logic is absolutely a sign of an aborted request)?

Or is it possible that alternate logic could be suggested, which would continue to work exactly the same for normal jQuery usage, but would alleviate this hitch with flXHR?

I have two suggestions along those lines:

1. Use some other logic to detect an aborted XHR request, not just readyState=0 after open() was called.

2. Don't start the looping "listening" interval immediately after open() as it does now, but start it only after the XHR object has moved out of the '0' state for the first time.

This '0-to-1' state change could easily be detected by initially attaching an 'onreadystatechange' handler to look for a movement out of the '0' state, at which point the handler/listener could be unassigned and THEN the interval looping logic would kick in.

Not only would this resolve the issue with flXHR... but, I would submit for your consideration that it's possibly a slightly more robust logic to use for this test. In other words, it's conceivable that there are other reasons why some browser's XHR object's open() command might not move the object immediately into the '1' state -- for instance, some internal code execution delay in some browser implementation (like activeX).

It would seem (to me at least) to make a little more sense not to start looping and listening for changes until you know the object has in fact moved to the '1' state fully, and is now clearly in the process of sending/receiving data.

I did a patch release for flXHR (1.0.2, http://flxhr.flensed.com/download.php) which now forces it to maintain a 'readyState' transition process which mimics more closely the internal native XHR, in that it moves the readyState immediately from 0 to 1, even if internally things are still waiting. This resolves the race condition (for now) between flXHR and jQuery.

However, for posterity sake, I would still renew my question/request that perhaps this logic be reworked a little bit for the next release, given my reasons above. Thanks.

Thanks for all your comments and thoughts on this issue. At least for now, I think we're going to have to leave the code as-is. Doing the abort check with readyState === 0 is best that we've found, so far, so I think we'd like to stick with it. On the plus side, it means that your code is that much closer to the "real deal" now :-)

If an alternative solution could be found, at some point, we can definitely re-open and re-examine the issue.