Was only consdering the world bounds, but buttons can have separate
hit areas that don't actually affect the bounds of the parent clip.
(TODO: Could have keep track of a separate mouse_bounds instead.)
Fixes regression in Mini-Putt 2 (#1120).
I originally added this with the anticipation that `impl` return syntax only allowed one trait plus OIBITs. This was prior experience in Rust but apparantly the compiler accepts this just fine, so I suppose my defensive coding practice was a bad/outdated idea.
This appears to work almost like it's own TObject method; you can run `Object.prototype.toLocaleString` on all sorts of things and it has separate behavior to what the class method for it might be. I have attempted to match Flash Player as best as I can.
The array being iterated is explicitly handed to all callbacks, and it is legal for the callback to mutate the array. Hence, we can't actually hold a `Ref` to the array storage when we call user code. Instead, we implement a custom `Iterator` which iterates over the object like user code would.
This actually can't be an `Iterator` impl due to limitations of the underlying trait. Hence, we have to `while let` instead of `for`.
This is for the sake of methods that want to change behavior based on if they're working with a number or some other kind of value. It should not be used otherwise.
This code also ensures that the prototypes of each system object are created in the appropriate `TObject` impl. This ensures that, for example, `new Array` hands you back an actual array.
The `fake_root` did not have an object, which could cause the
player to panic if the SWF was not completely loaded when playing.
Calling `post_instantiate` ensures that this dummy root has an
object.
There is a difference between empty/default (change value to default)
and none (don't modify), so make this explicit for some PlaceObject
parameters where it wasn't.
Fixes#1104.
Use eq_ignore_ascii_case when parsing HTML tags. Different versions
of Flash may export HTML tags with different cases, so this will
work a little better; however, we'll need a true HTML parser to
handle this robustly (for opening and closing tags with different
cases, for example).
* Implement `add`, with tests.
* Implement `add_i`.
There's no test, because for whatever reason, I can't figure out how to emit this from Animate CC 2020.
* avm2: Implement `bitand` with tests.
* Implement `bitnot` with tests.
* Implement `bitor` with tests.
* avm2: Implement `bitxor`
* avm2: Implement `declocal`, `declocal_i`, `decrement`, and `decrement_i`.
* tests: `swf_approx` tests should be allowed to print NaNs.
* avm2: Implement `divide`.
* avm2: Implement `inclocal`, `inclocal_i`, `increment`, and `increment_i`.
* avm2: Implement `lshift`.
* Implement `modulo`.
* avm2: Implement `multiply` and `multiply_i` (no tests for the latter)
* avm2: Implement `negate` and `negate_i` (no tests for the latter)
* avm2: Implement `rshift`
* avm2: Implement `subtract` and `subtract_i` (the latter without tests)
* avm2: Implement `urshift`.
removeMovieClip should only function on objects within a certain
depth range, usually to prevent removing timeline clips. However,
this wasn't working properly in some cases because the depth was
being biased incorrectly (removeMovieClip never takes a depth
parameter, so we should not bias the depth).
same_item_push was added on nightly, but is currently throwing
a false negative. I added an allow for it, but this causes a
warning on stable for an unknown lints, so allow unknown lints for
now.
This has some particularly annoying consequences for initialization order: notably, we can't actually create any ES4 classes using the standard machinery until after the three objects I just mentioned get created. Ergo, we have to create them through lower-level means, handing prototypes around, and then initialize AVM2's system prototypes list for it.
When we start adding more system prototypes, we'll also have to fill the extras with blank objects and then slot them in as we create them.
We're about to massively change the initialization process, and we really don't want to create another situation where the player can get caught with it's pants down.
This was surprisingly tricky - due to the need to look up superclasses, class trait instantiation requires an active `Activation` and `UpdateContext`. We can't get those during VM instance creation, since the player needs the VM first before it can give it a context to work with. Ergo, we have to tear the global scope initialization in two. At the first possible moment, the player calls a new `load_player_globals` method that initializes all class traits in global scope.
I have no idea why this is necessary - I was in a context where what *should* have been a `NativeMethod<'gc>` was instead being interpreted as some different function type with all the same lifetimes, but with an extra `'gc` lifetime as well. Funneling this through a non-trait method bypasses whatever is going on with the trait solver, and then at that point the trait solver knows what to do. Consider this an extra level of conversion.
ECMA-262 3rd ed. doesn't mention anything about different number types, so the standard as-if rule applies. If we are going to distinguish number types, we have to treat them as if they were the same type, promoting to `f64` as necessary to facilitate the conversion. I took a cursory look at an ECMA-262 4th ed. draft and it appears to do the same, although it calls everything `GeneralNumber` and has some really confusing psuedo-Pascal syntax for some reason.
I am extremely glad AVM2 does not provide access to 64-bit integer types (for now, at least).
Namespaces as values adds a bunch of extra special cases to the coercion and equality rules that don't really belong there. Namespace itself just returns it's URI as a string, so we can just make `NamespaceObject` do that and then treat it the same way we treat boxed primitives.