Bug Tracker

Opened 6 years ago

Closed 5 years ago

#14541 closed bug (notabug)

Active connections may not be closed in IE11

Reported by: dmethvin Owned by: dmethvin
Priority: low Milestone: 1.11/2.1
Component: ajax Version: 1.10.2
Keywords: Cc: jaubourg
Blocked by: Blocking:

Description

As of IE11, window.ActiveXObject returns false in a boolean context. That means the code at https://github.com/jquery/jquery/blob/dce2edb3a615f9de158607c9f8be83809373940e/src/ajax/xhr.js#L26 is never executed in IE11. Need to see whether connections still need to be closed there.

See #5280.

Change History (11)

comment:1 Changed 6 years ago by dmethvin

Component: unfiledajax
Milestone: None1.11/2.1
Priority: undecidedlow

comment:2 Changed 5 years ago by m_gol

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

comment:3 Changed 5 years ago by dmethvin

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.

comment:4 Changed 5 years ago by timmywil

Owner: set to dmethvin
Status: newassigned

comment:5 Changed 5 years ago by dmethvin

Cc: jauborg added

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?

comment:6 Changed 5 years ago by m_gol

@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?

comment:7 Changed 5 years ago by gibson042

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:

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.).

comment:8 Changed 5 years ago by dmethvin

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?

comment:9 Changed 5 years ago by jaubourg

@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.

comment:10 Changed 5 years ago by jaubourg

Cc: jaubourg added; jauborg removed

comment:11 Changed 5 years ago by dmethvin

Resolution: notabug
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.