Fix IE8/IE9 bug that may cause hanging cross-domain requests.

[asavoy]

When loading JS modules from another domain with StealJS, IE9 would not finish loading until I applied this patch.

See following descriptions of bug and workaround:

http://stackoverflow.com/questions/7037627/long-poll-and-ies-xdomainrequest-object/9928073#9928073

http://social.msdn.microsoft.com/Forums/ie/en-US/30ef3add-767c-4436-b8a9-f1ca19b4812e/ie9-rtm-xdomainrequest-issued-requests-may-abort-if-all-event-handlers-not-specified?forum=iewebdevelopment

(This was originally proposed in stealjs/steal#252)

[guybedford]

Do we need this as well? According to http://msdn.microsoft.com/en-us/library/ie/cc304105(v=vs.85).aspx it will default to 0 anyway?

[asavoy]

I didn't need timeout it for my particular case. But after reading other people's posts on this bug, there was one person who claimed they needed the timeout also. I thought it safest to just include it. Sorry I don't have the URL handy.

[guybedford]

Thanks for posting - this looks great.

[asavoy]

Unfortunately, I'm still seeing IE9 users reporting module load issues with this fix.

I can repro with an Win7/IE9 VM when I use Network Link Conditioner to simulate latency. I verified that it can be remedied with a second, more drastic fix (described in the links - wrapping the send() in a setTimeout()). But I still have users (multiple) repro'ing even with that. I'm now thinking that IE8/IE9's cross-domain XHR/XDomainRequest is just too buggy to be usable.

[guybedford]

@asavoy it seems that the setTimeout is something that is required for simultaneous requests (https://developer.mozilla.org/en-US/docs/Web/API/XDomainRequest).

I've added this on master here - 86ee1d9.

It would be worth verifying what the exact error is that users are getting - is it just a hanging issue?

[asavoy]

@guybedford

I have 4 different IE9 users describing the page as though no JS has loaded, consistently even after reloads. One of the pages is a simple Login page using only jQuery and a jQuery plugin. These users were able to use our site before we switched to the new StealJS that integrates SystemJS. (The old StealJS would load scripts via appending <script> tags) We've already modified our SystemJS similar to 86ee1d9 - but with a 50ms setTimeout().

I've asked one of the users to try InPrivate Browsing mode, to eliminate any browser extensions as the cause, to no effect. (I've asked them to try with a RequireJS version of the same page... but I think they lost interest in helping)

I've tested with a plain Win7/IE9 VM to find that everything works, but I found that using Network Link Conditioner to add a 500ms delay, I was able to reproduce the same effect consistently. Of course, it's hard to prove I was getting the exact issue, but nevertheless modules would not finish loading.

[guybedford]

@asavoy sorry to hear this has been affecting your users so badly. I'm surprised that no one else has reported these these issues even with the fixes though. I'm surprised that the implementation is really that buggy. In your reproducible tests have you tried changing the timeout value to a large integer? Perhaps add some logging to the XDomainRequest creation, onerror and onload functions to encapsulate the bug, and see if you can confirm with complete certainty it is this? If so, then yes, we need to look at CSP approaches for older browsers. But I find it hard to believe this is the case.

[guybedford]

@asavoy have you managed to find a workaround for this?

[stefanpenner]

Unfortunately, I've experienced something similar in the past. XDomain in IE9 get dropped, and the setTimeout as suggested at MDN improved the situation but did not resolve it entirely. We still had many unexplained dropped XDomain + postMessage requests when under-load. Some situations even resulted in all future requests also failing.

For us it did seem that as the number of XDomain + postMessage request increased the failures became more likely. I suspect the two may share some internals that cause them to cause each other grief.

Processing these in serial did solve the problem entirely, although resulted in a poor user experience.

Ultimately we gave up, and moved to support CORs via a proxy.

[guybedford]

Wow.

[stefanpenner]

its possible someone else has a real solution, so hopefully someone does.

[guybedford]

@stefanpenner thanks so much for posting your experiences with this. Perhaps we could generate an iFrame for each request to ensure the internal conflicts are avoided?

[stefanpenner]

possibly. our setup was an app with many frames. Once we added serial ordering per frame the problem went away, that being said the act of serial per frame may have easily caused the whole system to become serial and once again just reduce the likely hood. That being said, it would be worth a try I'm curious what the outcome will be.

[guybedford]

Thanks, I appreciated the feedback. Ok, I've posted an issue at #252 to try an experiment along these lines. I have no clue if something like that could work but it will be interesting to see.

[guybedford]

Have been trying to reproduce the bug here but can't seem to replicate it at all with 200 async requests and simulated latency and bandwidth. Have tried CPU loads as well during requests and can't break IE8! Does anyone have any tips on how one might replicate something like this?

[justinbmeyer]

@asavoy Can you create a VM that @guybedford might be able to use?