Agreed, this seems like it should call the error callback.

This appears because of the added onerror listener to xhr at https://github.com/jquery/jquery/blob/master/src/ajax/xhr.js#L110

Because this successfully fires (in chrome and safari) when trying an invalid url the try catch at https://github.com/jquery/jquery/blob/master/src/ajax.js#L649 throws an error instead of calling done() when chrome triggers a networkerror. Unfortunately throwing this error prevents the deferred callback from being called.

This can be fixed by delaying throwing the error by adding a setTimeout around throw e.

The alternative fix for this issue would be to remove the on error callback that is not consistently being called with all browsers or remove throw e line.

I will submit a pull request soon. Any feedback would be appreciated.

Awesome, thanks for the diagnosis!

Pull request: https://github.com/jquery/jquery/pull/1489

That's as edgy a case as I can imagine... and we tend to go by the "garbage in, garbage out" motto. The likelihood of such an invalid url not resulting from a programming error is very slim to say the least.

I'd vote against the "fix" but I'll let other weight in on this.

My use case was that to let the user configure the URL to an API and verify it by sending a simple GET request. Of course I could make sure the URL is valid first, but I expected jQuery to handle that (and I assume others do, too).

I can't comment on the fix though because I don't know a lot about the internals of jQuery.

Oh I wasn't implying your code was wrong or anything. It's just that it's a hack on top of a hack, albeit unavoidable given the goal you set here.

I'd need to check in the minutia of the XHR spec but if Chrome is going against the standard, then we can report a bug there and expect a fix in a timely fashion.

For the time being, you can catch the exception yourself (in parallel of an error handler) to cover your bases. Correct?

I can't reproduce in Chrome 32.0.1700.76 m nor in Chrome 34.0.1803.2 canary using this fiddle: http://jsfiddle.net/6Kjhr/1/

Am I "doing it wrong"(tm)?

That fiddle is using 1.10.2, which jakob said works. Look at the first fiddle (remove the /1).

/slapforehead :|

Yep, I can reproduce now: http://jsfiddle.net/6Kjhr/2/

Thanks Scott.

tl;dr: this is a bug in Chrome but there's a clean workaround for the time being.

Longer version...

Confirmed this is a Chrome bug, see https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/Overview.html#the-open%28%29-method, point 9.

Chrome fails to identify the URL as illegal and throws on send thinking it's a CORS violation.

Interestingly, Chrome calls onerror before throwing, apparently not onreadystatechange hence the difference in behaviour between 1.x and 2.x. For the latter, state is too "advanced" when the desperate-try-catch-of-no-return is reached. jQuery thus thinks there's an exception in a callback attached to the internal Promise or in its own code, something we clearly don't wanna shadow.

So the internal Deferred is resolved, but since everything happens synchronously, there's no time to attach the handlers. It works, however, if you use the callbacks options like so:

$.ajax( "//example.com:80q", {
    success: function () {
        log( "success", arguments );  
    },
    error: function () {
        log( "error", arguments );  
    },
    complete: function () {
        log( "complete", arguments );  
    }
} );

Those are deprecated though but there's a way to use the Promise interface: beforeSend, which gives early access to the jqXHR instance:

$.ajax( "//example.com:80q", {
    beforeSend: function( jqXHR ) {
        jqXHR.done( function () {
            log( "done", arguments );  
        } ).fail( function () {
            log( "fail", arguments );  
        } ).always( function () {
            log( "always", arguments );  
        } );
    }
} );

You can see it in action in http://jsfiddle.net/7LAVY/

I re-qualified the bug.

There are other valid circumstances where xhr.send may throw synchronously (data that cannot be serialized being one of them) so, despite the fact there's a bug in Chrome in your specific use-case, we still have to protect against these exceptions.

Since this is an xhr issue, the fix should be in the xhr transport, see the following PR: https://github.com/jquery/jquery/pull/1497

Thanks a bunch for discovering this, Jakob.

Ajax: Protect against exceptions thrown synchronously by xhr.send

When xhr.send throws an exception synchronously, the onerror handler may have

been called already which, unchecked, makes the exception bubble up outside of

jQuery.ajax.

We now catch the exception pre-emptively and only rethrow if we know it hasn't

already been notified through the onerror handler.

Fixes #14683

Changeset: 01c360f96390ff16edfe65ef3b34e167087ef645