Skip to main content

Bug Tracker

Side navigation

#14541 closed bug (notabug)

Opened November 14, 2013 02:47AM UTC

Closed January 03, 2014 01:37AM UTC

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:

As of IE11, window.ActiveXObject returns false in a boolean context. That means the code at is never executed in IE11. Need to see whether connections still need to be closed there.

See #5280.

Attachments (0)
Change History (11)

Changed November 14, 2013 02:48AM UTC by dmethvin comment:1

component: unfiledajax
milestone: None1.11/2.1
priority: undecidedlow

Changed November 28, 2013 09:17AM UTC by m_gol comment:2

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

Changed November 28, 2013 01:59PM UTC by dmethvin comment:3

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.

Changed December 02, 2013 03:44PM UTC by timmywil comment:4

owner: → dmethvin
status: newassigned

Changed December 24, 2013 09:05PM UTC by dmethvin comment:5

cc: → jauborg


According to this classic from 2006:

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?

Changed December 25, 2013 12:04PM UTC by m_gol comment:6

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


Changed December 25, 2013 05:55PM UTC by gibson042 comment:7

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:

  • "[ IE6+]"
  • "[ Firefox 18+]"
  • "[ Safari, IE9+]"
  • "[ 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.).

Changed December 26, 2013 03:39PM UTC by dmethvin comment:8

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?

Changed December 26, 2013 04:14PM UTC by jaubourg comment:9

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

Changed December 26, 2013 04:15PM UTC by jaubourg comment:10

cc: jauborgjaubourg

Changed January 03, 2014 01:37AM UTC by dmethvin comment:11

resolution: → notabug
status: assignedclosed

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

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