I noticed your code referenced from here: http://bugs.jquery.com/ticket/8283 and when I tried it out, it worked perfectly in IE8, but not on IE9. It looks like for IE9, you need to define the onprogress handler or requests will abort: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/30ef3add-767c-4436-b8a9-f1ca19b4812e
From my testing, setting this handler to jQuery.noop wasn't sufficient, but the empty function is.
Hope this helps someone!
Adding empty onprogress handler to workaround this bug in IE9: http:/…
Thank you guys for working on this. Julian, what are your thoughts on merging that one line to make this work in IE9?
@troyharvey I'm all for it. I'd just like to have a unit test to go with it.
I'm also doubtful about jQuery.noop not working and I think leaving an anonymous function on the xdr may cause the closure within which it is defined to leak -- it's IE we're talking about. Thing is I never found the time to tackle this.
@jaubourg Was there ever a unit test for it? Happy to update it if you point me in the right direction.
No there is none, and that's the problem, I'd need a unit test and do all the usual careful testing but I just didn't find the time :(
Still not working for me: http://www.stat.ucla.edu/~jeroen/cors/test2.html
@jeroenooms I'm convinced your specific case is a miscommunication between IE and your server that is not related to the issue at hand.
I tried my best to reproduce the issue... to no avail. No-one provided an actual reduced test case that would demonstrate the issue. I lost countless hours because of that.
I added a unit test to tentatively trigger onprogress handlers (and thus trigger the error) here: https://github.com/jaubourg/ajaxHooks/blob/master/test/unit/ajax/xdr.js#L18 Of course, it doesn't trigger anything but if someone wants to take this as a first step to demonstrate the bug, be my guest.
I added an onprogress handler set to noop and I now always set the timeout property and companion ontimeout handler (it seems the XDomainRequest instance can act weirdly if some field/handler is not set or so I read on the interweb). I also re-ordered everything so that open and send are called after setting the handlers and properties. Why? Because I suspect we have a race condition here which would explain the non-reliably-repeatable nature of this non-sense. Even if I didn't experience the bug, ever.
So, if someone wants to make a unit test that demonstrates the problem, you'd probably have to reset back to the transport as it was before.
I officially give up on this one: I couldn't reproduce the issue but I read stuff on the web and acted accordingly. Now, if you have a bug related to the XDomainRequest transport, open a new ticket with a reduced test case demonstrating the issue: if there is no test case, the ticket will be closed, period. Sorry to be that abrupt but I don't have enough hair to lose on wild goose chases, especially when IE and its horrid, stupid, outrageously useless dev tools are involved.
I had a request that worked a couple of hours ago in a Virtualbox Win7 image which was not fully up-to-date with patches. I rebooted, updates were applied and then the same request was aborted. This patch made it work again.