LoaderMax and LoaderContex issue

[FlexIncubator]

Hello.

 

I am trying to load multiple images from domains which do not have crossdomain policy file. As long as I do not need to modify loaded images, it should work for me. ImageLoader checks policy file by default, thus I have to specify not to do it. If we take just one ImageLoader object, then everything works as expected (I am specifying context var for ImageLoader):

 

var loaderContext:LoaderContext = new LoaderContext();
loaderContext.checkPolicyFile = false;

 

However, i can not make it work with LoaderMax. I am trying to specify my LoaderContext in 2 places, first in:

LoaderMax.defaultContext = loaderContext;

 

second by setting context var for each ImageLoader in for loop (where I am creating ImageLoader instances).

 

I got a lot of security errors in console when debugging, plus all contexts are null in all ImageLoaders.

 

Could you please clarify whether I miss something and why separate ImageLoader works while LoaderMax does not.

 

Thanks for help in advance,

 

Ilya.

[GreenSock]

It sounds like you're doing things correctly - could you post a super-simple FLA that demonstrates the problem (and generates the errors)? That way I can publish it on my end and see exactly what's going on.

[bcbirkhauser]

I am having the same issue. I am loading an xml file with multiple sub loaders (image, video, mp3). Due to limitations on where the files are placed, I cannot have a crossdomain policy file in place. I tried setting the Loadermax.defaultContext to not check the policy file, but I still get security sandbox violations, and all my files fail to load. What am I missing?

[GreenSock]

Please post a sample set of files with only the essential code to reproduce the problem/error so that we can publish on our end and see what's going on. (don't forget to zip your files before posting here).

[bcbirkhauser]

I found a workaround. Basically, the audit request was causing the site to fail because there was no crossdomain file. I added the estimatedBytes attribute to the xml for each loader and it no longer failed because it wasn't auditing the file. It seems like the audit request wasn't using LoaderMax.defaultContext, but the real load was.

[GreenSock]

The auditing process actually doesn't use a Loader object at all - it uses a URLStream which has no ability to define a LoaderContext. The URLStream is better for auditing because it is lighter weight and doesn't suffer from some of the gc issues that the Loader class does. However, I just updated LoaderMax so that ImageLoader and SWFLoader will automatically fall back to a Loader object for the auditing process if a security error is encountered. This should help resolve the issue you were running into. Please give it a shot and let me know if that resolves things for you (although your solution is probably even better if you can define estimatedBytes for each loader because that avoids the entire auditing process and speeds things up anyway but for situations where auditing is desired this fix should help).