As a test, I made this simple demo that illustrates the failure:

<script src="/scripts/swfupload/swfupload.js" type="text/javascript"></script>

<script>
var initUploader = function() {
swfu = new SWFUpload({
swfupload_loaded_handler : uploaderLoaded,
button_placeholder_id: "spanButtonPlaceHolder",
debug : true,
flash_url : "/scripts/swfupload/swfupload.swf"
});
}

window.onload = initUploader;

var uploaderLoaded = function() {
alert('test');
}
</script>

<span id="spanButtonPlaceHolder"></span>

Thank you, gyphie. That seems to have reduced the frequency, but it still happens about 20% of the time.

I have noticed, however, that it happens mostly when I'm testing locally with WAMP. When I move the code to a remote server, the issue is very rare. A timing issue influenced by how quickly things are loading locally?

JavaScript isn't throwing any unhandled errors that I can see. The only difference I see is the "SWF DEBUG: SWFUpload Init Complete" data outputting to the debug console before the "---SWFUpload Instance Info---
", which seems to indicate it thinks it's ready just a moment too soon.

Some more ... I put an alert in flashReady before the first line (var movieElement ...), and it always fires. I moved the alert right after the first line, and when it works it fires; when it doesn't, no alert fires, but no JavaScript error either.

We are still working on this issue. It is a caching problem and a bug in IE (this affects browsers like IE, Avant and Maxthon which are all based on the IE rendering engine).

@jerry: Generally you should not be modifying flashReady, any code should be in your swfupload_loaded_handler.

Our current line is to hope that even though IE isn't allowing the Flash to JS calls to be set up that the movie is still executed and that we can create some checks that will re-initialize them.

If that doesn't work the only other workaround we can think of is to write a server-side script that servers the SWF file and tries to send headers that prevents the browser from caching.

A new beta will be released soon but if you don't want to wait you can get the latest changes from the SVN trunk:

http://swfupload.googlecode.com/svn/swfupload/trunk/samples/demos/swfupl...
http://swfupload.googlecode.com/svn/swfupload/trunk/samples/demos/swfupl...

We've added a routine that checks to see if the ExternalInterface (all the StartUpload and GetStats calls) are available, if not then Flash tries to set them up again.

This seems to work well and fixed all the problems with DOM manipulation and CSS. But it did not make any difference in Opera. Surprisingly IE is the best behaved in this issue. But I could not reproduce the IE caching issue and can't be sure if these changes will fix that problem.

A couple issue to watch out for: The ExternalInterface check runs once every second. If you reparent the movie (or one of its parents) you must wait at least one second before you can be sure the ExternalInterface is restored or you may call a function that is not there getting similar results. (did any of that make sense?).

Further more, hiding or reparenting causes the Movie to reload (only reparenting causes this in IE). This means the Stats and any files queued are gone AND the file ID number restarts. If you are using the File ID as a reference in the page you can not rely on it being unique. We may try to address this before the beta is released.