Compare and contrast: If the handler function was declared from outside of the affected MovieClip, then got assigned as an event handler, this handler will run till its end, no matter that the MovieClip it got event from was removed using `removeMovieClip()` in the middle or not.

Test SWFs, source code, build scripts, and player logs are attached as `removemovie-events-fromroot.zip`.

So the termination is likely to be decided from code's closure scope: if handler's closure was destroyed on `removeMovieClip()` (e.g. the handler function was declared from inside the removed MovieClip itself), the affected handler terminates instantly.

On the other hand, if handler's closure was not affected by the `removeMovieClip()` call (e.g. it was declared on root or other MovieClip and got assigned in), the handler code runs until its end.

Gnash: 0.8.11dev (git f6a0b38 2-Jun-2016)
Flash Player: 11.2.202.491 Standalone
System: Debian GNU/Linux 7.0 Wheezy i386

P.S. The `removemovie-keydown-fromroot.swf` is affected by the same onKeyDown event issue as one mentioned in comment 3.


(file #37623)

I have tested few possibilities of how `MovieClip.removeMovieClip()` could get called and how it affects/terminates ActionScript runtime flow; it seems that Gnash reacted correctly in the simplest case, but not in more-advanced ones.

• removeMovieClip() called from timeline of the same sub-MovieClip: sub-MovieClip's timeline code terminated immediately under both Flash Player and Gnash.
• removeMovieClip() called from onLoad() handler*3 of the same sub-MovieClip: handler's code run till its end under both Flash Player and Gnash.
• removeMovieClip() called from event handler of the same sub-MovieClip:
  • called from onEnterFrame(): handler's code terminated immediately in Flash Player, but handler's code run till its end under Gnash.
  • called from onMouseDown(): handler's code terminated immediately in Flash Player, but handler's code run till its end under Gnash.
  • called from onKeyDown(): handler's code terminated immediately in Flash Player, but unable to test under Gnash*2.
  • called from function passed to setInterval(): function's code terminated immediately in Flash Player, but function's code run till its end under Gnash.

Test SWFs, source code, and build scripts are attached as `removemovie-events.zip`.

So, in the original Hostile Skies case, `removeMoveClip()` was called in sub-MovieClip's `onEnterFrame()` handler, which terminates it instantly under Adobe Flash. But under Gnash, the handler continued to run, so the it caught up in loop like @bwy mentioned in comment 1, and caused Gnash to freezes.

MakeSWF-based test cases might not suffice for this since it does not support sub-MovieClip. SWFTools' SWFC (or possibly, SWFCombine) is needed.

Note *1: I have yet to test on cases when other MovieClip calls `removeMovieClip()` on another MovieClip; so as when `removeMovieClip()` was issued from root MovieClip, or code inside #initclip of the same MovieClip (or root MovieClip).

Note *2: There seems to be another bug in Gnash that either caused keyDown event to fail propagating to sub-MovieClip, or caused `Selection.setFocus()` to fail bringing focus to sub-MovieClip.

Note *3: I have yet to figure out how to bind a method/class to a sub-MovieClip before attaching it to stage under SWFC or other free software tools (and not sure if it's possible), so I just have this case built under Macromedia Flash MX 2004.

Gnash: 0.8.11dev (git f6a0b38 2-Jun-2016)
Flash Player: 11.2.202.491 Standalone
System: Debian GNU/Linux 7.0 Wheezy i386


(file #37593)

It's still a bug. The problem appears to be a loop in an onEnterFrame clip event:

j = 2;
while (j <= 3) {
   // ...
   // Under some condition:
   this.removeMovieClip();
   ++j;
}

The call to removeMovieClip() makes j undefined, so incrementing it becomes NaN, and the loop never terminates.