Your sandbox is violating my security

Let’s suppose you come across the following error while debugging your AIR app:

*** Security Sandbox Violation ***
SecurityDomain 'file://.../art.swf' tried to access incompatible context 'app:/myapp.swf'

Let’s also suppose that you’re loading some artwork from art.swf – you’ve created some clips that you’re exporting for actionscript and you’re importing them in your app by using applicationDomain.getDefinition to get their class in to mypp. At some point in myapp you add some bits of that artwork to the stage you add some MouseEvents to a clip containing that artwork.

Suddenly when you try to interact with that clip, you start getting a whack of Security Sandbox Violations. Google to the rescue? Unfortunately, no. You will get a lot of Error #2048, 2122 posts but our simple art.swf doesn’t contain any code and isn’t trying to do anything funny. If you search for “*** Security Sandbox Violation ***” you’ll come across this stack overflow post which might give you an idea.

Perhaps Flash is trying to give the clip you imported from art.swf some kind of focus? A quick artwork.mouseEnabled = false, artwork.mouseChildren = false later and problem solved!

Some pseudocode to better demonstrate the solution:

// Load art.swf
// import class "Art" from art.swf
var my_art:Art = new art();
var my_clip:MovieClip = new MovieClip();
my_clip.addChild(my_art);
// Listeners that do mouse things...
my_clip.addEventListener(...);
// At this point, you may get your sandbox violated.. The solution?
my_art.mouseChildren = false;
my_art.mouseEnabled = false;
// Yay! Your security is safe

Flash Player Bugs – so much fun!

Public Advisory: If you have Flash Player version 11.0.1.152 installed, upgrade it! There are some strange issues in that release that can cause MouseEvents to not report… perhaps in connection to masking or scrollRects.

What follows is the -vvv story of how I discovered the issue and a recommended solution.

Over the weekend mysterious bug reports began surfacing. Coinciding with a major update on our site it seemed like we must have introduced a new strange bug.  I couldn’t believe we didn’t catch it sooner, but it was uncommon enough that it could wait until Monday. On Monday morning I began testing against older versions of our code and no matter how far back I would go, I could still reproduce the bug.  At this point, I was losing my mind – how could code that was working perfectly for more than a year suddenly stop working? I began testing other browsers, other operating systems and eventually saw the pattern: if you were using Flash Player version 11.0.1.152 you would encounter the bug. Annoyingly, 11.0.1.152 isn’t listed Adobe’s list of archived flash versions – if it had been it would have saved much debugging.

So, what to do? When you use swfobject you can specify the minimum flash version required for your swf. I didn’t want to force everyone to upgrade to 11.1 (our tools work in flash 10 and above), so I added an extra check before embedding our swfs. If your flash version matches 11.0.1.152 exactly, our minimum version is 11.1, otherwise it is 10.0. We get to take advantage of Flash’s streamlined expressInstall update process while allowing older users to stay put.

    var version = swfobject.getFlashPlayerVersion();
    v_check = '10.0.45';
    if (version.major == 11 && version.minor == 0 && version.release == 1) {
        v_check = '11.1.0';
    }
    swfobject.embedSWF(swf, id, width, height, v_check, ...);

Hopefully this information helps someone else who can’t understand why working code suddenly broke…