Air app swf assets in ApplicationStorageDirectory produce Sandbox Violation

Question

I have an Air application that lets users import jpg, png and swf files and use them as the source to an Image which they can drag around a Canvas.

The import function copies the selected file to an images directory inside ApplicationStorageDirectory.

When I click on an Image that has an swf as its source, I get a Security Sandbox Violation (eg. SecurityDomain 'app-storage:/Project1/images/menuBarBkgd.swf' tried to access incompatible context 'app:/Main.swf'). My mouseDown handler doesn't get called so I can't select it and allow it to be dragged.

Obviously this has something to do with the app: domain, but how do I get around this?

Answer 1

The answer posted earlier is not a solution to the original question. The issue at play here is SecurityDomain, not ApplicationDomain. I think there is a way to use swf files external to the app:/ domain in an Air application, but the documentation is far from direct on this issue and the eventual solution will probably require some intervention by the end user.

I was just trying to create a simple wysiwyg page editor and allow users to use images created as swf files as a source to mx:Image components. That worked! You can use swf files external to the app:/ domain as the source to an mx:Image. However, if you want to drag that around on a screen, as soon as you click on it you get the Sandbox violation and your mousedown event that starts the drag gets interupted. It seems that even if an swf file has no scripts in it, if any of the assets have been turned into movieClips (we're talking Flash here), then as soon as you click on them they try to reference the parent swf. The Air app interprets this as an external swf trying to script it and the Sandbox violation occurs.

The solution to this specific problem is to put the mx:Image inside an mx:Canvas and set the mouseChildren property of the Canvas to false.

Answer 2

Drag actions usually involve access to the stage, which belongs to the parent sandbox.

You've got a couple of options - one is to simply ignore / catch the error if it doesn't actually impact on functionality in the compiled Air app, which won't stop running necessarily on this kind of error (usually doesn't).

The other option is to refactor the functionality so that it doesn't access the stage. This is tough to do though as there seem to be some mouse events that try to get stage coordinates to populate their properties. I see this error a lot and it usually doesn't get in the way.