[Moderator: actually, as is stated later in the thread, this problem applies more globably than using Dojo only.]

flXHR (actually CheckPlayer) is set to look for swfobject library and dynamically load it if it's not already on the page. This works fine in all browsers and scenarios EXCEPT when Dojo is used, this causes an unrecoverable IE hang.

Actually, to be more precise, this bug only shows up when Dojo is loaded before flXHR (and thus dynamic swfobject). Additionally, it only shows up (for me anyway), when my IE7 cache is empty. Returning to the page (after force-closing the hung browser) works just fine. Essentially, this means its some sort of race-condition triggered when assets are pulled slowly from the server rather than quickly from cache.

To demonstrate that this has actually almost nothing to do with either flXHR or CheckPlayer (except the fact that they try to load swfobject dynamically), but is instead an incompatibility between Dojo and SWFObject, I've put up the following test pages which illustrate this problem. The first one loads Dojo first, then attempts to load SWFObject dynamically. An IE7 hang is created. The second one, the order of script inclusion is merely reversed, and the hang goes away.

http://www.flensed.com/code/dev-tests/test-scripts.html

http://www.flensed.com/code/dev-tests/test-scripts-2.html


I added this bug to SWFObject recently about this exact same topic:

http://code.google.com/p/swfobject/issues/detail?id=168

But as of right now, SWFObject is not agreeing that dynamically including swfobject is a valid use-case for their library.

As mentioned in another post, I'll duplicate here for posterity sake, the simple solution (although not ideal) is to either change the order of the script inclusion (as illustrated by the previous links provided), or to actually just manually include swfobject on the page, first, to take care of any issues Dojo has with it being dynamically loaded.

This looks like:

It appears this bug is caused by SWFObject's use of the document.write() of a deferred script tag with an invalid path (which they use for DOM readiness detection). SWFObject 2.2 is switching to another method of DOM ready detection, and so it is thought that this flXHR bug will be resolved at that time. However, since 2.2 is still in alpha, that updated version of their script will not be included in the upcoming flensed/CheckPlayer/flXHR 1.0 release, but instead addressed in a later patch/point release.

swfobject 2.2 is apparently doing away with the "document.write" method of IE DomReady detection. This *should* make this problem with Dojo (and others) go away.

It appears that this issue extends to jQuery as well, since I just started seeing fatal IE hangs/crashes on the flensed.com website after I started using jQuery and flXHR together. It appears, at the moment, that the workaround (the manual loading of swfobject script tag) works equally well here.

I'm gonna keep pushing on SWFObject to release a new version so that flXHR and CheckPlayer can stop having this potential issue in IE.

Just FYI as an update, the SWFObject team (which I'm now part of) is planning a release (v2.2) which in part will have a fix for this bug (removal of the need for the document.write() IE domready detection logic). When this happens (hopefully soon), CheckPlayer and flXHR will release a new patch including the new code, and this bug should be addressed.