-
-
Notifications
You must be signed in to change notification settings - Fork 940
core: Add compatibility flags #18974
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
As a matter of UX, we should definitely give the right column a more descriptive name like "FP default" so people understand what it means (and I guess a tooltip with further explanation could be good too) |
7b6a4ce to
16ce936
Compare
|
can this also used in the actionscript classes ? |
|
Another good one would be #3725 |
16ce936 to
67f837c
Compare
5a5f809 to
f600f02
Compare
|
Would it make sense to make this part of the "Open advanced..." options instead of being a global preference? Imagine someone who changes a flag to make a game work and then later plays a different game forgetting that they changed it and then that game doesn't work right because of the flag. You'd also have to ask about the flags each time each time you're troubleshooting. Another advantage of making it part of the launch options is that you could make it part of a Ruffle bundle, so you could bundle the game with the flags that are optimal for that game. I'm working on a Flash editor based on Ruffle. Part of the appeal of Flash for me is that it (with some exceptions, like device fonts) works the same on my PC as on someone else's. It would be annoying if my games didn't work for some people because they turned on a flag a long time ago and forgot about it. It would also be bad if someone used my editor to make a game, forgot that they had a flag turned on and accidentally relied on the behavior with the flag turned on. Then when other people try the game, it doesn't work right for them. |
Compatibility flags are used to configure behavior related to compatibility with Flash Player. The first compatibility flag added is TabSkip.
They are available under the --flags option.
This option configures compatibility flags applied during tests.
This flag configures the behavior of skipping some objects when tabbing. Flash Player skips those objects by default, however it's possible that some content is not aware of this (e.g. when objects are placed on a grid), and it results in reduced accessibility, as users cannot tab some objects.
This test verifies the behavior of TabSkip flag.
f600f02 to
12db9e5
Compare
I think it would. I wouldn't say that this PR is like the ultimate implementation of the GUI for compatibility flags, I'd rather treat it as the starting point and ability to put something behind a flag at all. The arguments you mentioned got me thinking and I'm rethinking whether saving compatibility flags to preferences is a good idea as of now.
I agree with that. But also note that the content deciding about stuff going on within Ruffle is not always the best idea. That's something we have to approach very carefully in order not to give too much control to the content. I'd say if we go with this, each flag should be assessed individually whether it can be set within the content. |

Compatibility flags help configure Ruffle by enabling and disabling specific behaviors.
They are meant to be used for instance in the following situations.
They fix bugs in Flash Player that make some content misbehave. Note that in general we don't fix bugs in Flash Player -- we are bug compatible. However, there are examples where a bug is so sneaky, some content could have been created with an assumption that the bug doesn't exist and the bug affects it.
They genuinely improve the experience of using Ruffle at the cost of lowering compatibility with Flash Player.
They improve the "perceived" compatibility at the cost of the "real" compatibility. For instance, something does not work in Flash Player, and we make it work.
The main goal of this PR is to prepare for adding new flags in the future. This way we'll have a simple interface to configure such behaviors in the future. The most notable example would be #18856 where we could add a compatibility flag which enables font fall back again for content that is not yet fully working in Ruffle due to various bugs.