You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a method on a superclass, this should look at the current object top-down when resolving properties, and not just from the current point in the prototype chain.
Test case:
classBase {
function Base() {
trace("// Base");trace(this["test"]);
}
}
classExtendedextendsBase {
var test ="Extended";function Extended() {
super();trace("// Extended");trace(this["test"]);
}
}
classExtendedFurtherextendsExtended {
var test ="ExtendedFurther";function ExtendedFurther() {
super();trace("// ExtendedFurther");trace(this["test"]);
}
}
new ExtendedFurther();
Expected output:
// Base
ExtendedFurther
// Extended
ExtendedFurther
// ExtendedFurther
ExtendedFurther
In ruffle:
// Base
undefined
// Extended
Extended
// ExtendedFurther
ExtendedFurther
The text was updated successfully, but these errors were encountered:
Dinnerbone
changed the title
avm1 super doesn't correctly resolve this properties
avm1 super doesn't correctly resolve this properties
Apr 11, 2020
I know how this happened. The underlying problem is how we handle super calls: super needs to remember how many levels deep we are in a call chain. The current AVM1 super implementation achieves this by maintaining a reference to the current super-prototype and super-constructor to call. However, preserving this across call boundaries is difficult. To get around having to extend call, I instead just passed super as this to the called function. This worked up until I started testing what superactually responded to in Flash Player. It actually does very little. For accuracy's sake, I reduced what super could do, which ultimately introduced this bug.
In my AVM2 proposal (PR #404), because super is NOT an AVM2 object, I couldn't store information in it. Instead, each call calculates a base_proto which is stored in the activation object, and the various super-related opcodes reference the activation's base_proto. I will attempt to backport this approach to AVM1 (where it actually makes more sense). This will also mean call and everything surrounding it will need to take a base_proto so that super and CallMethod can properly cooperate rather than the hacky AVM1 method of proxying stuff from super to this.
Well that's a difficult bug to summarize.
In a method on a superclass,
this
should look at the current object top-down when resolving properties, and not just from the current point in the prototype chain.Test case:
Expected output:
In ruffle:
The text was updated successfully, but these errors were encountered: