Early class construction is tricky - `Object` defines properties
that need to get copied into subclass instance vtables, but `Class`
defines `prototype`, which needs to be copied into the *class* vtable
of `Object`.
To accomplish this, I've split out instance vtable initialization
into a separate `init_instance_vtable`. We call
`object_class.init_instance_vtable` before
`class_class.init_instance_vtable`, but do things in the opposite
order for `into_finished_class` (`class_class.into_finished_class` is
called before `object_class.into_finished_class`)
Upon panic, `Ruffle::destroy()` attempts to mutably borrow the
thread-local `instances`. However, when a panic occurs, `instances`
is already immutably borrowed by `Ruffle::with_core_mut()`. This
causes the cleanup logic in `Ruffle::destroy()` to be skipped
altogether, and as a consequence the animation handler continues
to be fired, ultimately failing to borrow `instances` repeatedly.
Each time a borrow fails, a console error is logged.
Fortunately the fix is extremely easy - `Ruffle::with_core{,_mut}`
used to `drop(instance)` before running any potentially-panicking
logic, exactly for the reason explained above. But those functions
don't `drop(instances)`, which is subject to the same double-borrow
risk. So as a fix simply add `drop(instances)` in both functions.
With this fix, "Unable to lock Ruffle core" is logged on panic only
twice. These logs require further research, and will be avoided in
a future PR.
To avoid visual clutter, move some less handy options under a
collapsible area:
* Log level
* Ignore website compatibility warnings
* Maximum allowed ActionScript execution duration (description was
shortened in this commit)
* Preferred renderer
* Player version number
The suggested changes to the navigate_to_url handling in the feedback to
the pull request have been implemented.
Therefore, this commit consists of multiple smaller changes:
1. The allow_javascript_calls variable has been removed (as a CLI
argument and in the navigator). Javascript calls are now always denied
on desktop. This is because setting the argument was useless; no
javascript was executed in any case, at most, just a browser tab opened.
Therefore, it makes no sense to include this option.
2. The NavigateWebsiteHandlingMode default value has been provisionally
changed from Confirm to Allow. In the future (after a GUI toolkit has
been added), the default confirmation windows should include a "Save
this preference" checkbox.
3. The NetworkingRestrictionMode enum has been renamed to
NetworkingAccessMode since the previous naming was counter-intuitive.
4. The NavigateWebsiteHandlingMode enum (and variables related to it)
have been renamed to OpenURLMode to simplify the name.
5. The documentation has been improved.
The networking API restrictions imposed by the allowNetworking parameter
& attribute have been added and partially implemented.
A new NetworkingRestrictionMode enum has been added to Ruffle (in Rust
and Typescript). It contains the values "All", "Internal" and "None" and
models the possible values of the allowNetworking parameter / attribute.
All means that all networking APIs are permitted in the SWF file,
Internal means that the SWF file may not call browser navigation or
browser interaction APIs and None means the same and that the SWF file
cannot use any SWF-to-SWF communication APIs either.
A respective allowNetworking variable has been added to the JS config.
Its default value is All.
Ruffle now recognises the allowNetworking parameter and attribute in the
SWF HTML object and parses it and sets the config variable
correspondingly if it's recognised.
Only if the variable is set to All, the external interface (responsible
for javascript calls in AS3) is created. Additionally, the variable is
given to the WebNavigatorBackend and saved in it. The navigator denies
all navigate_to_url calls if the variable hasn't been set to All.
Therefore, the API restrictions imposed by setting allowNetworking to
internal or none have been partially implemented.
Formatting has been improved.
Nathan Adams