You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How it's supposed to be:
When you start an SWF with the command line, the NavigatorBackend::fetch method gets invoked and tries to read the file. If it doesn't have the necessary permissions to read the file, a fallback is used which asks the user to click open in a file dialogue to get the permissions.
If Ruffle already has the necessary permissions, it shouldn't need to do that and directly be able to open the file.
What happens instead:
When you start an SWF on macOS with the shell, you always get this fallback and file dialogue where you need to click open.
Even if you manually give Ruffle full disk access in the system preferences, Ruffle still gets the PermissionDenied error and needs to use the fallback to be able to read the file.
This happens independently to whether you use open ./Ruffle.app --args file.swf or ./Ruffle.app/Contents/MacOS/ruffle file.swf to open the SWF file.
Other notes:
It's not easy to debug this since the self-compiled version always has the permissions to read files; therefore this bug doesn't occur with it.
It also might make more sense to ask for permanent permissions to read that file since this fallback causes you to click through two windows (the explain window and the file dialogue) every time you start an SWF (even without this bug), and you'd need to manually give Ruffle disk access in the settings to stop this. Therefore, it would probably be better if Ruffle asked for being given the read permissions so it doesn't need to ask again every single time when starting an SWF. (You could also do both, ask for read permissions and if denied, still using the current fallback.)
The text was updated successfully, but these errors were encountered:
How it's supposed to be:
When you start an SWF with the command line, the
NavigatorBackend::fetch
method gets invoked and tries to read the file. If it doesn't have the necessary permissions to read the file, a fallback is used which asks the user to click open in a file dialogue to get the permissions.If Ruffle already has the necessary permissions, it shouldn't need to do that and directly be able to open the file.
What happens instead:
When you start an SWF on macOS with the shell, you always get this fallback and file dialogue where you need to click open.
Even if you manually give Ruffle full disk access in the system preferences, Ruffle still gets the PermissionDenied error and needs to use the fallback to be able to read the file.
This happens independently to whether you use
open ./Ruffle.app --args file.swf
or./Ruffle.app/Contents/MacOS/ruffle file.swf
to open the SWF file.Other notes:
It's not easy to debug this since the self-compiled version always has the permissions to read files; therefore this bug doesn't occur with it.
It also might make more sense to ask for permanent permissions to read that file since this fallback causes you to click through two windows (the explain window and the file dialogue) every time you start an SWF (even without this bug), and you'd need to manually give Ruffle disk access in the settings to stop this. Therefore, it would probably be better if Ruffle asked for being given the read permissions so it doesn't need to ask again every single time when starting an SWF. (You could also do both, ask for read permissions and if denied, still using the current fallback.)
The text was updated successfully, but these errors were encountered: