The relevant code in 1.x has a Support: IE<10 entry suggesting it's not an issue for IE10+.

I'd just like to see a test case proving that. If IE11 fixed it then the current detect is perfect. There's no way the comment anticipated the problem being fixed before IE11 arrived, we've always had a hard time expressing open browser bugs that way.

Hmmmm.

According to this classic from 2006:

http://ajaxian.com/archives/reusing-xmlhttprequest-without-abort

The code in 1.x-master shouldn't have this problem anyway because afaict it attaches the handler *after* it does the open. We never got a test case in #5280 so it's possible the code we have isn't necessary at all.

@jaubourg, your thoughts?

@dmethvin: I meant that the code suggests that the problem doesn't even exist in IE10, not to mention IE11. The comment may be wrong, obviously.

IMO we should document our support comments syntax. From what I understand, we sort-of have a convention that:

1. "Support: Browser version", "Support: Browser version1, version2" mean that the bug exists in mentioned versions but we didn't check / can't yet check in newer versions.

2. "Support: Browser < version" means the bug is fixed in "Browser" in version "version".

3. "Support: Browser" means the bug may still exist. We should avoid this form as it says very little.

This would mean that if we have bug in IE6-9, we should write "Support: IE6-9" and not "Support: IE<10" before we make sure IE 10 really fixes that issue.

Thoughts?

I agree that "Support: Browser < version" should indicate that our support code is confirmed unnecessary in the identified version, but I read "IE6-9" as identical to "IE<10" (the latter being a shorthand made possible by our support matrix). My preference is a "+" to indicate unchecked but presumably valid ranges:

• "[https://github.com/jquery/jquery/blob/7468461569fa2908aa84f162b3ad7cfda42b46bf/src/ajax/xhr.js#L10 IE6+]"
• "[https://github.com/jquery/jquery/blob/7468461569fa2908aa84f162b3ad7cfda42b46bf/src/intro.js#L43 Firefox 18+]"
• "[https://github.com/jquery/jquery/blob/7468461569fa2908aa84f162b3ad7cfda42b46bf/src/attributes/prop.js#L93 Safari, IE9+]"
• "[https://github.com/jquery/jquery/blob/7468461569fa2908aa84f162b3ad7cfda42b46bf/src/event/support.js#L9 IE<9 (lack submit/change bubble), Firefox 23+ (lack focusin event)]"

The only thing we need to be more diligent about is updating our comments as we confirm behavior of later browser versions ("IE6-11+"; "Firefox 18-26+"; etc.).

The trailing "+" seems like a good solution, making it clear that we don't know whether something will be fixed in a newer release and it will possibly require re-testing.

For this case I was looking for a simple way to unit test the problem, but stumbled across that old message saying it wasn't needed if you did the operations in a particular order, which it looks like we do. Since there was never a repro for #5280 I am hoping we don't need the code at all, anywhere.

@jaubourg, it looks like the original fix was applied during the 1.5 rewrite, do you recall if you had a repro?

@dmethvin, If I understand the article you linked to correctly, it deals with re-using an XHR instance (as in the same javascript object). That's clearly not the problem we fixed by aborting on unload. What I tested (and sadly reproduced) was that, if you had pending requests when the document was unloaded they were never "released", so you'd end up with IE refusing to create new XHR instances (or queueing when requesting, I don't remember exactly) in the __next__ page. Very nasty bug.

Okay, I created a fiddle to see if IE11 aborted the sessions.

http://jsfiddle.net/dmethvin/BMQM2/

Using Fiddler I can see that IE11 does cancel the outstanding XHRs when you navigate to another page.