The flag is used for ongoing QA/test purposes in environments where command-line switches can't be used (e.g. The flag is regularly used for support/debugging purposes, by asking users to flip it to eliminate a possible problem (such as ignore-gpu-blocklist). Permanent flags (those with expiration -1) should only be used when either: Flags are backed by either a feature or a set of switches, which they enable at browser startup depending on the value of the flag.įlags should usually be temporary, to allow for pre-launch testing of a feature. 
Flags also have an expiration milestone, after which they will be hidden from that UI and disabled, then later removed. Flags have a name and description, and show up in chrome://flags. These are implemented by adding an entry in about_ describing the flag, as well as metadata in flag-metadata. FlagsĮxample: chrome://flags/#ignore-gpu-blocklist An exception to this is when the configuration value is a string, since features can't take an arbitrary string value. New code should use base::Feature instead of switches. In general, switches are inferior to use of base::Feature, which has the same capabilities and low engineering overhead but ties into UMA reporting.
Are not configurable via enterprise policy (except on Chrome OS, via FeatureFlagsProto). There is no centralized registry of switches and they can be used for essentially any purpose. These are implemented by testing anywhere in the codebase for the presence or value of a switch in base::CommandLine::ForCurrentProcess. Are not automatically persistent across restartsĮxample: switches::kIncognito aka “-incognito”. Are not configurable via enterprise policy. This is done by consulting the testing config for Chromium builds, or a Google-internal tool for Chrome builds.įeatures are the best way to add runtime conditional behavior. Do note that in release builds, only a series of hashes show up in chrome://version rather than the string names of the variations, but these hashes can be turned back into string names if needed. Which features are in use is tracked by UMA metrics, and is visible in chrome://version as the “Variations” field. These can be enabled via server-side experimentation or via the command-line using “-enable-features”. These are implemented via creating a base::Feature anywhere. Are automatically persistent across restarts (usually). 
Are not localized into the user's language.They can be directly configured via enterprise policy. There are several pref stores, which are documented in detail in the prefs docs. They store typed values, which persist across restarts and may be synced between browser instances via the Sync service. Prefs are implemented by registering them with a central pref service, usually via Profile::RegisterProfilePrefs. Example: prefs::kAllowDinosaurEasterEgg aka “allow_dinosaur_easter_egg”
0 kommentar(er)
