While developing the YUI Charts, I discovered a nasty bug with ExternalInterface that affects many versions of Flash Player 9. Basically, it involves overwriting parts of the data passed from JavaScript somewhere in the encoding or decoding process. The best way to describe this error is to explain with an example.

Consider the following Flex application. Once it is initialized, the application calls a function named flashReady() in the hosting page’s JavaScript. The function returns a complex object to display in the Flex app’s Tree control.

Click image to run the application.

Source code for the Flex app:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" applicationComplete="getDataFromJavaScript()">
	<mx:HBox>
		<mx:Tree id="tree" width="250" height="300"/>
		<mx:TextArea id="parsedData" fontFamily="Courier New" fontSize="12" width="250" height="300"/>
	</mx:HBox>
	<mx:Label id="status" text="Loading Data..."/>
	<mx:Script>
		<![CDATA[
			import com.adobe.serialization.json.JSON;

			private function getDataFromJavaScript():void
			{
				if(ExternalInterface.available)
				{
					var result:Object = ExternalInterface.call("flashReady", []);
					this.tree.dataProvider = result;

					//we're only encoding to JSON to view the result in the TextArea
					this.parsedData.text = JSON.encode(result);

					//version displayed for easy identification
					this.status.text = "Flash Player Version: " + Capabilities.version;
				}
				else
				{
					this.status.text = "ExternalInterface is not available!";
				}
			}

		]]>
	</mx:Script>
</mx:Application>

The following structure is passed from JavaScript to ActionScript.

var dataToPass =
{
	label: "Level 1-A",
	children:
	[
		{ label: "Level 2-A" },
		{
			label: "Level 2-B",
			children:
			[
				{ label: "Level 3-A" },
				{ label: "Level 3-B" }
			]
		},
		{
			label: "Level 2-C",
			children:
			[
				{
					label: "Level 3-C",
					children:
					[
						{ label: "Level 4-A" }
					]
				},
				{ label: "Level 3-D" }
			]
		}
	]
};

As you can see, the data passed through ExternalInterface has a complex hierarchy. Many of the objects have a label variable and many have children to specify branches in the Tree.

With Flash Player 9.0.28 (it affects other builds, but that one is commonly installed), the parsed data displayed in the TextArea control looks like the following code block. I’ve manually formatted it for readability.

{
	"0" : { "label" : "Level 4-A" },
	"children" :
	[
		{ "label" : "Level 4-A" }
	],
	"1" : {"label" : "Level 3-D"},
	"2" :
	{
		"0": { "label" : "Level 4-A" },
		"children" :
		[
			{ "label" : "Level 4-A" }
		],
		"1" : { "label" : "Level 3-D" },
		"label" : "Level 3-D"
	},
	"label" : "Level 3-D"
}

You’ll notice that the label property is overwritten on many of the more shallow levels. The strange numeric variables come from the indexes of the various children Arrays. Clearly, much of the data gets completely lost. You can see the very nearly empty Tree control in the following screenshot.

Thankfully, Flash Player 9 Update 3 (build 9.0.115) properly handles this type of ExternalInterface data. However, one can hardly expect everyone to install the very newest version that isn’t even a month old yet.

For the YUI Charts, I needed to find a way to get around this problem in older versions of Flash Player 9. Using the YUI JSON Utility, I encoded the data provider and various other complex properties to simple strings before passing them through ExternalInterface from JavaScript to ActionScript. On the ActionScript side, the JSON data can be decoded with AS3 corelib to turn it back into native objects.

For public releases of Flash Player (official releases and those appearing on Adobe Labs), this bug seems to affect builds below 9.0.60 (the beta version of Update 3, mentioned above). It shouldn’t affect too many applications out there as ExternalInterface isn’t widely used, in my experience. For those out there that do make heavy use of this API, it’s definitely a concern, and you will either need to resort to encoding the data somehow or requiring FP 9.0.115 as the minimum version if you discover that you’re affected.

By the way, if you ever need to test older versions of Flash Player, Adobe provides nice zipped downloads of each major version (with multiple builds of each) back to Flash Player 2.

Recently, I’ve been hacking at low-level AS3 features to try to find a way to load an external image and make a class out of it. Basically, I want to create multiple instances of that image using only the new operator. The image path isn’t known until runtime, so I’d like to make a special Loader subclass that knows the correct image path to load before it gets instantiated. As you can imagine, that’s not the easiest requirement to meet.

Example Application (View Source Enabled)

A short time ago, Ben Stucki created a class to load external images as icons for Flex components. It’s a very clever solution. He uses a Dictionary to associate the image path with the intended parent. I wish I could have used it, but the class I’m trying to create needs to be instantiated somewhere that I can’t access the parent. Like I said, the class itself really needs to know the correct image URL to load. In AS2, it wouldn’t be too difficult to accomplish. You can hack __proto__ in AS2 to do some interesting runtime subclassing to make a unique class for every URL. Unfortunately, Adobe locked things down a bit in AS3 (for performance reasons, mostly), and __proto__ is no longer accessible to developers.

That said, let’s try to remember back even further, to our AS1 days, when true classes didn’t exist. Classes were function objects, and we added member variables and methods through prototype. Thankfully, class-like functions through prototype are still possible in AS3. Consider the following code:

var MyImageClass:Function = function():Loader
{
	//we need a Loader that automatically loads our image
	var loader:Loader = new Loader();

	//the URL will come from the prototype
	loader.load(new URLRequest(this.url));

	//our "constructor" returns the Loader!
	return loader;
};

//the image to load in our dynamically created "class"
MyImageClass.prototype.url = "yahoo_logo.gif";

This creates a constructor-like function that returns an instance of Loader. This loader automatically loads an image URL that we place in the function’s prototype. If you’re using Flex, you could easily modify this function to make it return a SWFLoader instead.

Usage is surprisingly simple. We pretend MyImageClass is a real class, and our friend the new operator takes care of everything.

//add two images to the display list
var image1:Loader = new MyImageClass();
this.addChild(image1);

var image2:Loader = new MyImageClass();
this.addChild(image2);

Two images will automatically load. That’s perfect!

…well, sadly, it’s not perfect. There’s some bad news. I had hoped this would be able to replace Ben’s code in Flex too, but I quickly discovered that while this special pseudo-class (as I now call it) behaves like a real class, Flash Player knows that it isn’t a real Class. For example, the icon style on the Button component in Flex expects a Class object. Our pseudo-class is actually a Function object, and these two types are not compatible. Flash Player will throw a runtime error if I try to set this style to a Function.

Thankfully, I need these pseudo-classes for a component that I built myself. I can ensure that I type my variables correctly (or at least branch depending on the type) so that both Class and Function can be used. As much as I’d like to be able to use these pseudo-classes for icon and skin styles in Flex, that’s just not in the cards.

If you’re interested, I built a utility class called LoaderUtil with a function createAutoLoader() that encapsulates this functionality into a simple function where you pass an image URL, and an optional LoaderContext (for tweaking cross-domain options and other stuff on the Loader), and you receive one of these pseudo-classes back.