Memory leaks with IE9 and IE11

[cchristine]

This is not an issue or bug with SWFService. There is an idea below that could be integrated into SWFService to help with the IE9 and IE11 memory issue mentioned below, but in no way should this construed as saying that there is bug with SWFService.

I have found an issue with IE9 and IE11 and AS3 derived events serialized over the ExternalInterface ActiveX (Windows OS) bridge on those versions (at least) of the IE browsers.

The issue is that when dispatching an AS3 Event derived object from flash, which eventually gets sent across the bridge in the redispatch from SWFServiceListenerProxy, the culprit appears to be the target and currentTarget members of the AS3 Event class, which in my case references an object with a lot of string data and lots and lots of stuff that needs to be escaped.

Injecting an event that has target and currentTarget nulled out does not help, as the flash framework between dispatching the event and SWFService receiving it will populate these members for you. This means that SWFServicelistenerProxy has no choice but to serialize a complete AS3 event. In many cases this is exactly what you want, but of course, with the IEs that may lead to trouble like I found.

My solution to this has been to create child classes for SWFService, SWFServiceContext, SWFServiceProxy and SWFServiceListenerProxy that allow you to register an (optional) callback when you call register on SWFService that will be used to "intercept" the event in SWFServiceListenerProxy.redispatch and convert the event into something more lightweight for serializing across the bridge. If no callback is specified, then you get the default behavior. If the callback is specified, then your return value from calling the callback with the original event will be used to serialize across the bridge rather than event itself.

This allowed me to create an Event Proxy class (that does not inherit from AS3:Event), that has only the data from the event that we need to the JS side, and nothing more. It also allowed me to ensure that none of the members encapsulated by this proxy are dynamic, which again, may help with IE memory leaks by allowing tighter control over what passes through the bridge. Note, there is a side benefit that for our application, the proxy event is much smaller than the AS3 Event derived objects that we use on the flash side, so we get better performance.

Initially, I besmirched the SWFService code-base to do all this directly, which was a lot less code. however, I do not want to be deploying an app with a modified version of SWFService, so the inheritance route was architecturally superior. However, it would be fairly easy to modify SWFService to do this directly, and the default behavior if no callback was specified would be to operate as before.