Resolving `_levelN` had some inconsistencies with Flash:
1. `_flash` can be a prefix too.
2. The level ID parsing cannot fail; non-digit characters are ignored,
the value wraps around at `i32::MAX`, and negative values are valid.
This logic is relevant also for the `GetUrl` and `GetUrl2` opcodes.
For now only add TODOs for this.
This PR adds the following class stubs:
* 'flash.display.Loader'
* 'flash.net.URLRequest'
* 'flash.ui.Keyboard'
* 'flash.utils.Timer'
These are needed for 'This is the Only Level TOO' (though we'll need
actual implementations to get this game past the loading screen).
Previously, `isFinite()` with no arguments on SWF<7 incorrectly
returned `true`, as `undefined` coerced to `f64` is `0.0`, which
is finite. Fix this by not defaulting to `undefined`, similarly to
the `isNaN()` implementation.
Instead of returning a `Result` which is anyway always handled with
a `log::warn!()`, simply `log::warn!()` in place of errors. This
removes the last 3 remaining `Error` enum members besides `InvalidXml`.
The 2 existing usages of `remove_node` always operated on a child and
its parent: One iterates over all of its children and removes each one,
and the other explicitly grabs the parent of a given node.
As a simplification, `remove_node` operates only on a child node,
without the need for the parent node in addition; it grabs the parent
from the child by itself. As such, it's non-failable.
Text nodes are guaranteed to not be parents, as `adopt_child`
refuses to adopt children into them. So instead of returning an
`Err(Error::TextNodeCantHaveChildren)` in case of a text node parent,
mark those code paths as `unreachable!()`. This makes `orphan_child`
non-failable.
The `json` crate seems unmaintained, and recently also causes compile
errors with stable Rust 1.59.0. On the other hand, `serde_json` is
very maintained and more popular.
However, from some reason a cyclic package dependency has introduced
by this change. For now use a workaround from: https://github.com/tkaitchuck/aHash/issues/95#issuecomment-903560879
This is basically a revert of 61298b2be3.
`SharedObject`s used to be saved as JSON in Ruffle, but since #4238
they're saved in AMF to match Flash's behavior. The legacy JSON
deserialization remained for backwards-compatibility, but from what it
seems, it has never worked; cd1cde1708
changed `LocalStorageBackend` to store base64-encoded strings instead
of plain ones. Therefore, Ruffle attempts to base64-decode old JSON
data, and unsurprisingly fails.
In addition, this removes 1 out of 2 usages of the unmaintained `json`
crate, which recently also causes compile errors with stable Rust 1.59.0.
The only use of `last_parse_error` was in the `XML.prototype.status`
property, where it was converted into a number. Avoid storing it by
storing just the number.
Revert some of e50aea864b for an even
better approach - Remove `XmlNodeObject::empty_node` entirely by
making `XmlNodeObject::from_xml_node` a suitable alternative. That is,
being able to accept a custom `proto` like before.
Also, make it return an `XmlNodeObject` instead of an `Object`, and
add a few `.into()` where needed.
* Don't use `quick_xml::Writer` for formatting the XML, being much
more simple.
* Return `WString` instead of `String`, reducing `to_utf8_lossy()`
calls except when the string needs to be escaped (attribute values
and text contents).
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`.
dependabot[bot]