[Bug] Timeline audio in nested child clip loops when parent is made to gotoAndStop(1) after playing once. FP 18.0.0.324+, FP19, FP20
Essentially, once a movieclip has been played, directing it to gotoAndStop(1) will cause audio within its child clips to loop, even if the timeline would never be allowed to trigger the sound.
We noticed this bug popping up in a lot of delivered product, and traced it back to the FP 18.0.0.324 update (.225 is OK).
Debug setup: Even after replacing the IDE's projector with FP20, it still doesn't present when previewed from Flash; but it will present in the projector, FF, AX, and Chrome plugins.
Create movieclip "wrapper" on main timeline with at least 2 frames.
Create movieclip "subclip" within wrapper at least a few frames long. Embed audio on a keyframe in subclip. Any keyframe.
For my test, subclip is never allowed to play, and the audio is located on frame 5. Frame 1-4 contain "stop()" and an event dispatch for debug purposes.
Add this code to the main timeline
wrapper.addEventListener("blah",foo);
function foo(e:Event):void{
wrapper.removeEventListener("blah",foo);
wrapper.gotoAndStop(1);
}
and have wrapper dispatch a "blah" event on it's last frame.
Result: When viewed outside of IDE, "wrapper" plays once, stops, and audio clip begins to loop with a repeat time based on the duration of subclip, despite the fact that subclip does not actually play. I added a text box and piped some debug text to it so that subclip would report its current frame, and it never leaves frame 1.
Mysterious!
Bonus: I mapped mouse click to SoundMixer.stopAll(), but it only silences one instance. Not sure if it that is a useful detail, but it suggests that each iteration is a new instance, again, as if the clip itself were looping.
Workaround: Playing the audio via code (Sound.play()) instead of embedding it in the timeline doesn't trigger this bug.
Edit: (Hopefully that is sufficient to recreate. I can provide a FLA upon request, had thought there was an "attach" ability on this forum.)
Edit 2: I forgot the Question! Is there any workaround to this that can be achieved via a publish setting, or something global? We have hundreds (thousands?) of files to fix for our clients if this bug doesn't get patched out before they update past FP 18.0.0225.
