Link to issue number:

As per PR #13851
Also merges in support for multi value feature flags: #13871

Summary of the issue:

NVDA increasingly makes use of feature flags to expose experimental changes to users.
There are already several approaches already in use.
It is easy to miss use-cases for changing default behavior, potentially overriding an advanced users preferred config.

Some feature flags require more than just a Boolean enabled/disabled outcome (in addition to 'default'), E.G.:

• AllowUiaInMSWord [WHEN_NECESSARY, WHERE_SUITABLE, ALWAYS]
• AllowUiaInChromium [WHEN_NECESSARY, YES, NO]

Several approaches have been tried:

• Store an int in the config that match with enum values, as per (AllowUiaInMSWord and AllowUiaInChromium)
• Use "options" in config (several string values). Literal strings in code to compare refer to these.

These approaches can hide errors:

• Looking at the config, what are the valid values when an integer is used.
• Using string "options":
  • what are the valid options?
  • how do you find all usages?
  • Change the strategy for default?
• For both, when looking at the config or configSpec, how can the behavior of default be determined?

Description of user facing changes

The target user of this change are developers.
This introduces constructs and utilities to streamline the approach to adding feature flags.

Adding a new feature flag:

• Most feature flags can use the BoolFlag.
• If more values are required, define a new enum class in featureFlagEnums.py (include a DEFAULT member) E.G.: MyNewFeature
• Add the entry to the configSpec.py E.G. shouldUseMyNewFeature = featureFlag(optionsEnumClass="MyNewFeature", behaviorOfDefault="ON_WEEKENDS")
• Add a GUI option for it, using FeatureFlagCombo
• Wrap the code for the feature with config.conf["section"]["shouldUseMyNewFeature "] == MyNewFeature.ON_WEEKENDS

Description of development approach

Introduction of a generic BoolFlag type (enabled/disabled) which needs to account for 3 states:

• The current NVDA default (IE user has no preference)
• User has a preference of enabled
• User has a preference of disabled

To facilitate this, one of the three values (default, enabled, disabled) is stored in the config.
Spec/config transformations are provided to streamline the support.
A featureFlag type in the spec is automatically converted to a FeatureFlag class instance.
The FeatureFlag class abstracts the consideration of "default", allowing the FeatureFlag to treated as a boolean within internal NVDA logic.

A utility GUI control is added which presents the FeatureFlag option to the user, and allows developers to give translated names to the logical values (enabled, disabled), the name for default incorporates the behaviorOfDefault (and is also translated).

Note:

• The configSpec explicitly defines what the behavior of default is.
• The enum class that backs the config is defined, allows for type / value checking.
• Existing flags have not been upgraded, these would require upgrade code for the config, this introduces unnecessary complexity.

Testing strategy:

• Unit tests added to illustrate and test spec / config transform and validation.
• Manually tested various options, including updating from config in Load Chromium virtual buffer on state_system_busy #13851

Known issues with pull request:

This approach bypasses the handling for defaults provided by configObj.
It was considered whether the default not written on read behavior (of the configObj library) to facilitate the third (default) state.
However:

• This would require explicit code to test for the existence of the key to know if the value returned by conf["section"]["myKey"] was just the default or an explicit setting.
• It also requires careful diligence to ensure that the value is not ever written accidentally.
• Code to delete the key is required whenever attempting to return to the default.
• The way validation checks are created in configObj makes transforming the type (to provide an abstraction) difficult. It is not possible to get access to the default without a similar approach used in this PR. If adopting the complexity of a spec and config transform step, then it is preferable to have explicit values for default. Explicit values make the config easier to inspect and make the approach more robust.

Change log entries:

For Developers

- A config spec type ``featureFlag`` has been created for use with experimental features in NVDA. See devDocs/featureFlag.md for more information.

Code Review Checklist:

• Pull Request description:
  • description is up to date
  • change log entries
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• API is compatible with existing add-ons.
• Documentation:
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English