Tuesday, October 4th, 2005

Category: Flash

MovieClip.unloadMovie bug in Flash Player 8

This may get classified as a security “enhancement” but it’s a bug as far as I can see. Perhaps someone can enlighten me as to how this is a good thing …

Summary:
When you load a movie from a web server and the main movie is not in the same domain, you can’t get any properties of the loaded movie, including depth. You also can’t unload it.

This isn’t a rant about how I can’t access data inside a remote SWF - that is a part of security and I have no problem with that.

However, there are certain things that the parent should be able to control, and blocking access to everything on the loaded clip is nothing but lazy. MovieClip.getDepth has no purpose for the loaded clip, but is signficant to the parent. And as if you can’t unload the movie you just loaded! Wrong.

The setup:

Parent movie

  • - created in Flash 8.
  • - published as SWF 8 with network access only.
  • - creates an empty movieclip on _level0 and loads a movie from a web server.
  • - a button to let you unload the movie, well not really.

Child movie

  • - contains a shape so we know it’s been loaded.
  • - place on a web server.

The remote movie is allowed to be downloaded and loaded into the main movie, but there is no way to remove it! I have found no way to remove the loaded movie through the parent only. Perhaps using System.security.allowDomain in each SWF will allow me to remove the movie, but that shouldn’t be necessary.

I find it hard to believe that no one else has come across this. Have you? If so, how do you unload a movieclip from another domain?

I am quite willing to be proven wrong here.

I should mention that I also tried adding the parent SWF and the child SWF’s domain in my list of trusted sites on the half-baked Global Settings page, but that didn’t help.

7 Responses to 'MovieClip.unloadMovie bug in Flash Player 8'

Subscribe to comments with RSS or TrackBack to 'MovieClip.unloadMovie bug in Flash Player 8'.

  1. Patrick Mineault | Tuesday, October 4th, 2005 | 8:15 pm

    Even attempting to use allowDomain will yield unsatisfactory results. I currently proxy the remote files using PHP, it’s 4 lines of code and stops me from banging my head against the wall… repeatedly. For example:

  2. tonypa | Wednesday, October 5th, 2005 | 4:52 am

    Create mc1. Create mc2 inside mc1. Load movie into mc2. You can now remove mc1 (and loaded movie) with simple:
    mc1.removeMovieClip ();

  3. Mike J | Wednesday, October 5th, 2005 | 8:56 am

    Heh, we ran across some of these things being cut off in FP7 too, for instance, not being able to get myloadedmovie._parent! Of course the goofy thing in FP7 was we were able to get around it by just getting the path of the loaded clip (it will spit that out) and parsing the MC path to get the parent.

  4. Derek Vadneau | Wednesday, October 5th, 2005 | 11:59 am

    UPDATE: I was able to remove the movieclip by using createEmptyMovieClip with the same depth.

    Of course if you’re building a movie that uses automation then not being able to get the depth is rather impeding.

    [EDIT] - F#$%ing WordPress! Sorry everyone for missing the comments. Comments were awaiting moderation and I never got the notifications … flippin’, frickin’, arg!

  5. Derek Vadneau | Wednesday, October 5th, 2005 | 5:59 pm

    @ Patrick and Mike:
    Ugh, I know. System.security.allowDomain should allow you to kill security for that domain/movieclip. However, it only enables instance-level access. You can’t access each others’ _global, for instance (punn totally intended ;) )

    Setting allowDomain before a loadMovie should mean the loaded movie can access everything just like it was loaded from the same domain. I can see this being a problem if Flash needs to know if the loading movie accepts the permissions as well (by setting allowDomain), but if there’s a crossdomain.xml file, then, as I said, they should be treated as though they were loaded from the same domain. Anything less is false security anyhow.

    @ tonypa:
    That’s pretty nifty as a workaround. I appreciate the assistance - luckily I wasn’t on a deadline. However, that’s not the way the Flash player *should* behave. It is a bug that can be worked around, but it’s still a bug that should be fixed.

    @ All:
    I personally think a lot of this security is unnecessary, and puts security in the wrong place. If I put a file on the web I should expect that people can access it. If I don’t want people to access my file I can choose to not put it in the public domain or use server-side security measures (which are much more potent anyhow).

    What good is allowing me to download a graphic from another web site in Flash, but then not allowing me to unload it or get properties of the movieclip containing the graphic? - Here I’m speaking of the security sandbox, where a local SWF can still download a JPG from a server, where it couldn’t do that with a SWF or XML file.

    Anyhow, this is turning into a rant worthy of another post, so I’ll just say, thanks to everyone that read/commented. And again, my appologies for not releasing the comments sooner. I’ll make sure to check my admin section regularly. Anyone who did comment won’t need to go through that process again.

    Thanks.

  6. cpbrooks | Wednesday, August 16th, 2006 | 4:37 pm

    I found this page looking for a fix of this problem (thank you very much for mentioning it), and tried implementing the tonypa fix which, of course, works. But I ran into hassles trying to fix all my references to the external swf holder (the mc1). So instead I added an extra frame to the timeline with no holder clip, and a put a prevFrame action on it. Then when I want to unload the clip, I just send the timeline to the blank frame. Just another down and dirty fix.

  7. Stéphane | Tuesday, October 10th, 2006 | 10:15 pm

    Please help me, i’ve tried both solution and apparently i didn’t do it right because none of them work…. somebody here is kind enough to accept FLA from me ?

Leave a Reply

If this is your first comment it will need to be approved before it will appear.