ExternalInterface Out Of Memory Error

With the release of Flash Player 9, one of the web sites for which I am responsible began throwing "out of memory" errors in Internet Explorer. This happened when a user would navigate away from the page. Stepping into the debugger revealed the following problematic code:

function __flash_unloadHandler() {
mySwf.style.display = 'none';
for (var prop in mySwf) {
if (typeof(mySwf[prop]) == "function") {
mySwf[prop]=null;
}
}
if (__flash_savedUnloadHandler != null) {
__flash_savedUnloadHandler();
}
}

function __flash_setupUnloadHandler() {
if (window.onunload != __flash_unloadHandler) {
__flash_savedUnloadHandler = window.onunload;
window.onunload = __flash_unloadHandler;
}
}

__flash_setupUnloadHandler();

My first reaction was "Whaa? I didn't write any of that code", but then I remembered this neat little article by Brad Neuberg showing how the Flash Player uses JavaScript methods for serializing incoming ExternalInterface calls. So, my problem was related to ExternalInterface.

A quick search for "ExternalInterface out of memory error" yielded the following Flashcoders discussion: http://chattyfig.figleaf.com/pipermail/flashcoders/2006-July/168998.html. So I was not alone, and it seems the issue is related to having multiple swfs using ExternalInterface on one page.

(The same search also turned up this page, where Geoff Stearns talks about fixing problems with audio streams and SWFObject. The code which fixes Geoff's issue looks mighty familiar when I look at my debugger.)

The part where IE gets stuck is in executing __flash_savedUnloadHandler(); At first glance it looks to me like __flash_savedUnloadHandler() would be executed for every swf you have embedded in your page. In the Flashcoders thread I referred to earlier, Alexis Glass suggests the problem may be related to the fact that the unload handler is saved in a global variable:

...it saves the previous unload handler in a global variable so that if
ExternalInterface is initialized twice on one page it recursively calls the
__flash_savedUnloadHandler until IE complains about no memory.

It may be possible to override the faulty JavaScript, but I don't want to go down that road for fear it will break with a future release. So, I will have to revert back to good ol' FSCommand and getURL for the time being. Yuk. Anybody got something better for me?

As an aside, in my research I also came across John Dowdell's response to Brad Neuberg's original article. I know it's a bit dated now, but the ensuing comments are interesting, because John seems to be focused on the context of Brad's usage of ExternalInterface, whereas Brad seems to be offering the exact points of failure. It seems that John is saying "You're out of scope, the point is moot" while Brad is saying "My personal scope of use is not important, here are in-scope examples of how ExternalInterface is broken". I encountered the same "perspective gap" when dealing with Macromedia's customer support folks a few years ago. They seem to be trained to focus on the context in which you are using the functionality, so they can offer alternate means to your particular end. But that can be frustrating when you are trying to present a unit test which is failing for no particular reason, and they are preoccupied with the question of why you want to do it in the first place.