Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

avm1: References to removed clips should be "resurrected" if the name is reused #1513

Closed
Herschel opened this issue Nov 6, 2020 · 0 comments · Fixed by #9447
Closed

avm1: References to removed clips should be "resurrected" if the name is reused #1513

Herschel opened this issue Nov 6, 2020 · 0 comments · Fixed by #9447
Labels
A-avm1 Area: AVM1 (ActionScript 1 & 2) bug Something isn't working

Comments

@Herschel
Copy link
Member

Herschel commented Nov 6, 2020 •
edited
Loading

Consider the following sequence:

  1. On frame 1, there is a movieclip with an instance name of "clip". var clipRef = clip; on frame 1.
  2. Remove the clip on frame 2. trace(clipRef); traces the empty string (clip is dead, but not implemented yet, cc [Skeleton Park] Issue with a specific animation #993).
  3. Add a completely new clip named "clip" on frame 3. trace(clipRef); magically prints _level0.clip even though clipRef was never updated.

This seems like avm1::StageObject must store the canonical path to the movieclip, and will automatically point to a new clip if that path is ever reused. Some research is needed to determine the exact behavior, and hopefully figure out an efficient implementation (worst case is we have to parse the path on every use, which would be bad...!) My hope is that we can limit this check to only when the original clip is removed.

Example SWF using timeline:
dead-mc-timeline.zip

Example SWF using createEmptyMovieClip twice w/ same name and depth:
dead-mc.zip

I believe this causes #1415 and #1509. Related to #993.
@Herschel Herschel added bug Something isn't working actionscript A-avm1 Area: AVM1 (ActionScript 1 & 2) labels Nov 6, 2020
@Herschel Herschel mentioned this issue Nov 7, 2020
Closed
This was referenced Apr 23, 2021
Closed
Closed
This was referenced Jun 19, 2021
Merged
Merged
@relrelb relrelb mentioned this issue Jul 3, 2021
Open
@Kippykip Kippykip mentioned this issue Jul 11, 2021
Open
@Herschel Herschel mentioned this issue Oct 17, 2021
Closed
4 tasks
Herschel added a commit to Herschel/ruffle that referenced this issue Oct 17, 2021
@Herschel
avm1: Reference display objects indirectly by string path
ea06521 
AVM1 display objects do not actually hold pointers to their display
object, but instead refer to them indirectly via string path (for
example, `_level0.clip.foo`).

This means:
 * Every property access on an AVM1 display object requires
   re-resolving the path to the actual object.
 * If that display object is removed from the stage, the AVM1 object
   still exists, but the the path no longer resolves to a display
   object, so the reference is "dangling". Any operations on the
   AVM1 object are noops.
 * If a display object with the same path is later added to the
   stage, the AVM1 object will once again resolve, and all
   operations will work using the new display object.

Fixes ruffle-rs#993, ruffle-rs#1415, ruffle-rs#1513, ...
@Herschel Herschel mentioned this issue Oct 18, 2021
Closed
@moulins moulins mentioned this issue Jun 26, 2022
Merged
@adrian17 adrian17 mentioned this issue Sep 20, 2022
Closed
@CUB3D CUB3D mentioned this issue Dec 31, 2022
Closed
CUB3D pushed a commit to CUB3D/ruffle that referenced this issue Dec 31, 2022
@Herschel @CUB3D
avm1: Reference display objects indirectly by string path
04b5ac7 
AVM1 display objects do not actually hold pointers to their display
object, but instead refer to them indirectly via string path (for
example, `_level0.clip.foo`).

This means:
 * Every property access on an AVM1 display object requires
   re-resolving the path to the actual object.
 * If that display object is removed from the stage, the AVM1 object
   still exists, but the the path no longer resolves to a display
   object, so the reference is "dangling". Any operations on the
   AVM1 object are noops.
 * If a display object with the same path is later added to the
   stage, the AVM1 object will once again resolve, and all
   operations will work using the new display object.

Fixes ruffle-rs#993, ruffle-rs#1415, ruffle-rs#1513, ...
@CUB3D CUB3D mentioned this issue Feb 7, 2023
Merged
24 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-avm1 Area: AVM1 (ActionScript 1 & 2) bug Something isn't working
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

avm1: Reference display objects indirectly by string path CUB3D/ruffle
1 participant
@Herschel