As `XmlDocument` and `XmlObject` had 1-to-1 relation, and `XmlDocument`
is already tightly coupled with AVM1, there's no good reason for them
being separate objects.
This brings us one step closer towards an XML implementation hosted
completely in AVM1.
A future PR will merge `XmlNode` into `XmlNodeObject` in a similar
manner.
Instead of storing shared pointers to `Avm1ConstructorRegistry` in
`MovieLibrary`, access the `PropertyMap` directly, without an extra
abstraction.
Also, move the constructor registries to `Avm1`, for better
encapsulation.
Instead call `XmlNode::script_object`, which internally calls
`XmlNode::introduce_script_object`. This is a preparation for changing
the signature of `XmlNodeObject::from_xml_node`.
Currently it is not directly possible to configure lints for the
entire workspace via TOML, which forced us to repeat `#![allow]`
blocks in each crate.
embark pointed out this workaround to configure lints at the
workspace level via RUSTFLAGS:
https://github.com/EmbarkStudios/rust-ecosystem/issues/22#issuecomment-947011395
Remove the common `#![allow]` blocks and switch to this method for
global lint config.
Temporarily allow `needless_borrow` lint, buggy pending this fix:
https://github.com/rust-lang/rust-clippy/pull/8355
Previously we called `toString` when concatenating a string to an
Object. However, Flash actually has more complex behavior, usually
calling both `valueOf` and `toString`. This is loosely based on
ToPrimitive/DefaultValue with no type hint in the ECMAScript spec.
* Call `valueOf`.
* If the result isn't a primitive, call `toString`.
* If the result still isn't primitive, return `"[type Object]"`.
* For Date objects in SWFv6 and higher, call `toString`.
* If the result isn't a primitive, call `toString` (AVM1 bug?)
* If it still isn't primitive, return `"[type Object]"`.
This also rearranges some things about how we construct events, because `MouseEvent` has different defaults from `Event`. When we finally support parameter metadata on methods we should remove that code.
We also remove the `value_of` code on `EventObject` as that was a mistake. Events don't do anything special in there and I misinterpreted the test results the first time around.
This requires adding another notion of mouse-release events to `ClipEvent`. We now have four:
* `MouseUp` - the mouse was released, any object on the render list can handle this event ("anycast" event)
* `MouseUpInside` - the mouse was released inside this display object, only the mouse-picked target of the event can handle it
* `Release` - the mouse was released inside the last clicked display object
* `ReleaseOutside` - the mouse was released outside the last clicked display object
For those keeping score at home, in AVM2, the valid progression of events is either...
* On the same object, `mouseDown`, `mouseUp`, and `click`
* On one object, `mouseDown`, then some mouse movement that takes the cursor out of the first object, then on another object `mouseUp`, and then finally the first object gets `releaseOutside`.
`MouseDown`/`MouseUp` are effectively broadcasts; they hit every movie clip that can accept them until one of them has a handler for it. AVM2 instead wants events that only apply to specific mouse-picked display objects, which means we need to use the Player-tracked events `Press`, `Release`, and `ReleaseOutside`. The only problem is that we also need to emit a `mouseUp` event on both `Release` and `ReleaseOutside`.
relrelb