That's way too much code. Can you provide a simple test case that doesn't require external libraries? Even if it's just a standalone file. Otherwise, it's likely that the problem is caused by one of the other things in the file. See also #13883 which seems to be reporting the same problem, but also was too large/unclear.

I have hosted the application on this URL: http://signalr01.cloudapp.net:82/

Now, your repro code is minimal, only the HTML and JS available on the browser :)

I'm sorry but I can't reproduce it. Here's a test case on jsFiddle:

http://jsfiddle.net/5YGVB/1/

http://jsfiddle.net/5YGVB/1/show/light/ (a standalone test without iframes)

I used a web page http://mgol.eu/sandboxes/longwait/ I've just created. Its whole code is:

<?php
	sleep(6);
	header('Access-Control-Allow-Origin: *');  
	header('Content-Type: application/json');
	echo '{"a":2}';
?>

You can use this page for your tests if you want but we do need a test case on jsFiddle to be able to investigate. If your problem require a different response, I can update the PHP test but you can also do it on your own server; just remember to set the Access-Control-Allow-Origin header to * or jsFiddle won't be able to start an AJAX request against this page.

Use a word document as the file to download.

I can repro the issue when the link is created as "<a href". The issue goes away when the link is created as "<a download href".

"download" keyword is HTML5 so it works only on latest browsers.

So does this problem happen with all browsers? What OS are you using?

OK, I can reproduce it, situation is as follows (I changed the test case to not use the download attribute):

1) Chrome & Safari fail the test

2) on Firefox always & fail fire.

3) on IE10 always & done fire.

I'm unable to test IE9 in this way because it doesn't support CORS.

http://jsfiddle.net/5YGVB/2/show/light/

Thanks for your report, gustavo!

#13883 is a duplicate of this ticket.

jaubourg claims it's not possible to fix this one without re-introducing all the logic from 1.x.

Reassigning to jaubourg so that he can close the bug as wontfix if he wishes.

@jaubourg, can you provide some more background about why this happens? I assume it has something to do with our switch from onreadystatechange?

It's a browser issue. Clicking on a link will abort outbound requests. The fact this is a download link is irrelevant. On mobile Safari, for instance, downloads will be on a new page. Fact is, browsers will abort early, before they know if an actual in-place navigation will occur.

Of course, this behavior is not 2.x specific.

Oh that makes sense, and it's something we can't control.