The default allowScriptAccess value for polyfilled elements has been set
to samedomain. This means that it's true if the SWF file has the same
domain as the player website and false otherwise.
To do this, a new isPolyfillElement parameter is given to the
RufflePlayer::load method.
Previously, the Ruffle configuration options weren't working properly
for polyfilled elements.
A polyfilled element can have specific configuration options which
overwrite the more general Ruffle configuration settings.
But the code handling those specific configuration options has
previously set some of them to default values if they haven't been
provided, therefore overwriting the more general configuration settings.
This has been fixed. A getPolyfillOptions function has been created and
returns a URLLoadOptions object, containing only the options that have
been set for the respective element. Helper functions have been adapted
to not return any default values anymore.
getPolyfillOptions is now used in all places where polyfilled options
need to be retrieved (therefore reducing duplicated code).
Documentation has been added to clarify that these options must not
contain any default values, since those would overwrite other
configuration settings with a lower priority.
The extension and demo code has been changed to clarify that no default
values are contained in the element configuration options.
The RuffleEmbed::attributeChangedCallback method has previously loaded
an SWF file only with the parameters and base options. This has been
fixed as well since it now also uses getPolyfillOptions.
When using RuffleObject::connectedCallback to load an SWF file, setting
an element config option to "" hasn't worked for most config options
before either. This has been fixed as well by using the new
getPolyfillOptions function.
The default WindowMode value of the default Ruffle web config has been
set to Window (as it is in the desktop version and according to the
documentation). It has previously been set to Opaque (which causes the
same functionality).
* web: Improve styling of extension pop-up menu
* web: Improve styling of extension settings page
* web: Improve styling of extension player
* web: Make styling more consistent across browsers
* web: Run eslint, fix some problems
* web: Move version text near top of pop-up menu, add to settings menu
* web: Improve logo hover bounds in pop-up and settings
* web: Improve styling of extension status indicator
* web: Update extension pop-up text strings
* web: Misc. sizing/padding changes to extension UI
* web: chore: Add a stylelint exception for #backgroundColor in player.css
Because it's not kebab-case, to match the keys of the metadata object in JS.
---------
Co-authored-by: TÖRÖK Attila <torokati44@gmail.com>
Previously, the volume transformation to adapt the volume for
logarithmic hearing has been performed in the VolumeControls Rust struct
and TypeScript class each.
Since this calculation is the same on desktop and web and should be
implemented in the audio backend, it has been moved into the
AudioMixer::mix_audio method.
The VolumeControls struct and class now only calculate the linear volume
out of the checkbox and the slider.
Player::set_volume and Player::volume now don't take and return the
adapted volume, but use the linear volume (which gets saved internally).
The web version of Ruffle now has a volume controls window. It can be
accessed through the right-click menu (Right-click > Volume controls).
It contains a mute button and a slider from 0 to 100.
To achieve this, a new volume controls modal has been added to the
shadow template.
TypeScript is used to create texts, set the controls and add event
listeners to update the settings and controls when being changed.
The volume settings set in the GUI are saved in a new VolumeControls
class, which is also used to calculate the real volume (adapted for
logarithmic hearing) out of the entered volume and the mute checkbox.
As soon as the volume is changed in the GUI, the real volume will be set
in the Ruffle instance.
The existing ftl files have been adapted (and new ones have been
created) to include the new multilingual text in the right-click menu
and the volume controls window.
This closes#1771.
* web: Remove most occurences of innerHTML
* web: Use helper methods for shadow template element creation
* web: Refactor createErrorFooter function
* web: Shadow template code cleanup
* web: Add helper function to add CSS rules to shadow template
---------
Co-authored-by: nosamu <71368227+n0samu@users.noreply.github.com>
When using a 'Loader', properties on the 'contentLoaderInfo' become
set during specific events in the load sequence. In particular,
'LoaderInfo.bytesTotal' becomes available during the first 'progress'
event.
Also, 'LoaderInfo.parameters' is now properly set from the URL query
parameters. In Flash player, this work even with filesystem urls
(e.g. 'file:///some/path/to/file.txt?paramOne=valOne' will load
a file named 'file.txt', setting and expose the parameter 'paramOne'
with value 'valOne' in `LoaderInfo.parameters`). This required some
cleanup to the desktop and test NavigatorBackend impls to strip
out query parameters when loading a parameter from disk.
Previously, we would set `SwfMovie.parameters` manually from the url.
Now, the various `SwfMovie` constructors automatically extract
query parameters from the provided url. Outside of `SwfMovie`,
we only append *extra* parameters (e.g. those set from `flashvars`).
This makes CPMStar ads work, since the loaded SWF needs to access
`LoaderInfo.parameters`
After a panic, `Ruffle::renderer_debug_info()` cannot be called since
it tries to immutably borrow the underlying `Player`, but `Ruffle::tick()`
already holds it mutably.
As a fix, simply use the `_cachedDebugInfo` which is fetched in
advance, before any panic occurs. Rename it to just `rendererDebugInfo`
(without "cache" in its name), because now it's mandated.
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.
New configuration options (changing the navigate_to_url call handling)
have been added. The default behaviour has been changed as well.
A NavigateWebsiteHandlingMode enum has been added to Ruffle (in Rust and
Typescript). It contains the values "Allow", "Confirm" and "Deny" and
describes how navigate_to_url website calls should be handled. Allow
means that all website calls are allowed, Confirm means that a
confirmation window opens with each website call and Deny means that all
website calls are denied.
A respective navigate_website_handling_mode variable has been added to
the desktop CLI and to the JS config. The default value is "Confirm" in
each. The variable is given to the navigator (ExternalNavigatorBackend
or WebNavigatorBackend, depending on the platform) and is saved in it.
On each navigate_to_url website call, the respective navigator is now
checking navigate_website_handling_mode and acts correspondingly (allows
it, opens a confirmation window or denies it).
This changes the default behaviour of Ruffle from allowing all website
calls to opening a confirmation window with each website call.
On Safari, the confirm window can cause the background music to stop,
but this seems to be an issue with Safari.
Closes#838.
Additionally, an allow_javascript_calls variable (which defaults to
false) has been added to the desktop CLI. The variable is given to the
desktop navigator and is saved in it.
If a navigate_to_url javascript call is executed on desktop, the
navigator is now checking allow_javascript_calls and acts
correspondingly (allows it or denies it).
This changes the default behaviour of Ruffle on desktop to not allowing
javascript calls.
Closes#9316.
The problem seems to have been the inclusion of setting values
that the previous equality function did not handle correctly.
This function broadens the kinds of setting values that can
be handled correctly.
The option 'max_execution_duration' previously only supported
the type '{secs: number, nanos: number}'. Now it also supports
using floating point numbers (and integers).
Default values have been changed to use floating point numbers.