There were some well publicized major security changes for policy files and the filereference class included with the Flash Player 10 security updates but a seemingly less significant new restriction regarding cross domain swf focus can wreak havoc on an existing flash project . The new restriction is outlined here:
Related-object properties in events may not be available

Starting in Flash Player 10.0.2, if an object that would be referred to by any of these properties [MouseEvent.relatedObject, FocusEvent.relatedObject, ContextMenuEVent.mouseTarget] resides in a different security sandbox (for example, because it is part of a different SWF that was served from a different domain), and the two sandboxes do not both trust each other (by means of the Security.allowDomain method), then the value of this property is changed to null.

I’ve found this is a significant change for cross domain swfs that utilize any of Flash’s V3 Components. Some 3rd party crossdomain swfs that once worked fine will no longer focus properly when clicking on textfields. Digging into this component architecture’s FocusManger you can find the culprit:

fl.managers.FocusManager::mouseFocusChangeHandler(event:FocusEvent)

The solution is to add a Security.allowDomain(“YourDomain”) if you have access to republish, otherwise you’d have to use a proxy server.

Note that because it uses:
urlRequest.requestHeaders.push( new URLRequestHeader( ‘Cache-Control’, ‘no-cache’ ) );

You may get SecurityError:
Error #2044: Unhandled securityError:. text=Error #2170: Security sandbox violation: http://domain1.com/your.swf cannot send HTTP headers to http://domain2.com/yourscript.php.

You may need to add a variation of <allow-http-request-headers-from domain=”*” headers=”*”/>  to your crossdomain.xml file or comment out that line. I chose the latter as I don’t think its neccessary in a POST call.

-Build-in fix for the Firefox 3/Mac OSX blinking effect.

I was looking into interfacing with some Facebook APIs today via actionscript and was having some issues passing some nested querystring vars. Turned out using escape() wasn’t enough and encodeURIComponent() did the trick. I didn’t realize it was even available in actionscript until i did some googling. encodeURI() and encodeURIComponent() are available along with escape() as top level functions in AS3.

Here’s a useful link explaining the difference between them.

My Google-foo (or Adobe?) has let me down on getting solid information on this but in my tests it appears this functionality changed with Flash Player Debugger 9,0,115,0 (Yeah, I thought it was earlier too). This is the debugger version that installs with Flex so even tho you may no longer get the prompt its keen to note that any viewer with a <9,0,115,0 Flash 9 debugger (like the 9,0,45,0 debugger that installs with Adobe CS3) will still receive it. In most cases this isn’t anything to worry about though as its second nature to turn off debugging on your production swf. However did you know you have to take into account all embedded and run-time loaded swfs as well?

After receiving reports of said infamous debugger on our production swfs and a lot of time spent investigating with Flash Switcher I found a couple insignificant embedded icon swfs and a few run-time loaded font swfs were the debug swf culprits. Duplicating the issue in the Flash 9.0.45.0 Debugger, what made matters worse is that each debug swf that loaded was getting its own modal popup and, atleast in Mac FF3, each consecutive modal popup was showing up blank but still needed to be clicked or the user was locked out of the site.

After another extensive google search the only thing I could find regarding this child swf debugger policy is a brief mention in Tinc Uro’s Blog regarding Flash Player 9 Update 3 (again Player 9,0,115,0). The one line from his release notes was: “210746 When a release swf loads a debug swf, flash player doesn’t look for the debugger”.  I’m assuming that this was the “fix” as this player version does indeed keep the issue from happening. So to prevent your viewers from ever getting spammed with “Where is the debugger” modal windows, ensure all your swfs (embedded and run-time loaded) are non-debug or force your viewers to update to the most recent flash player if they don’t have atleast 9,0,115,0.

With the proliferation of “dot” releases of the Flash Player its now really important to know which sub version of the player you are targeting. Looking at the Flash Player 9 version penetration rates at KickApps I was surprised to find around 80% of our audience had atleast 115. I’m not sure of the remaining 20% how many are debug players though.

Version        Penetration
9,0,124,0:    ~56%
9,0,115,0:    ~24%
9,0,47,0:     ~10%
9,0,28,0:      ~7%
9,0,45,0:      ~4%

stage.addEventListener(MouseEvent.MOUSE_DOWN, function(event:Event):void { event.currentTarget.removeEventListener(event.type, arguments.callee); trace(‘ran once’); });

FYI you should always use event.currentTarget and not event.target when removing a mouse event listener because event.currentTarget will always reference the object that the listener was explicitly attached to. event.target can easily reference a different object like a child displayObject inside the displayObject you were listening for a bubbling event on.

I’ve been doing some run-time class loading involving loading SWF files into the same ApplicationDomain as the container via Loader then using getDefinitionByName to access new instances of the loaded classes. I was perplexed that the INIT and COMPLETE events weren’t being dispatched and found some info here.

Generates:
SecurityError: Error #2000: No active security context.
at global/flash.net::navigateToURL()
at Function/http://adobe.com/AS3/2006/builtin::apply()
at <anonymous>()
at SetIntervalTimer/onTimer()
at flash.utils::Timer/_timerDispatch()
at flash.utils::Timer/tick()

A work around is to wrap the call in an anonymous function:
setTimeout(function():void { navigateToURL(urlRequest, “_blank”); }, 1000);

Creating a “smart” proxy with the URLLoader for text content is a piece of cake. Simply listen for the SecurityErrorEvent then run the url through the proxy. Beautifully simple.

For the Loader class its a different story. The Loader class’s contentLoaderInfo doesn’t have a security error event, just an ioError event. Your supposed to use the childAllowsParent property of the contentLoaderInfo to figure out whether you have bitmapData level access. The only problem is you can’t access that property until the Event.COMPLETE event is dispatched despite the livedocs LoaderContext page stating this property is available on ProgressEvent.PROGRESS which will throw a Error #2099: The loading object is not sufficiently loaded to provide this information. at flash.display::LoaderInfo/get childAllowsParent()

I can finagle with the LoaderContext and try/catches all I want but there doesn’t seam to be a creative solution to this problem. The result: I have to load every image that doesn’t have a policy file TWICE. Once to check childAllowsParent, the next to proxy the image. This doesn’t make any sense considering on the same livedocs LoaderContext page it states:

When you call the Loader.load() method with LoaderContext.checkPolicyFile set to true, Flash Player does not begin downloading the specified object in URLRequest.url until it has either successfully downloaded a relevant cross-domain policy file or discovered that no such policy file exists.

I can see the “Error: Request for resource at http://… by requestor from http://… is denied due to lack of policy file permissions.” errors being outputted to the console window but I don’t seam to have a way to catch it in code. Is something as significant as this, really a bug? Can anyone give me a hand?

UPDATE: This does appear to be a bug with proper policy files checking with the Loader class.  The solution: use UILoader for the check, then use Loader with or without proxy. Thanks Brian from picnik.com for the example below in comments.