Chrome://flags is a powerful tool for developers and advanced users to experiment with experimental features in the Chrome and Chromium browsers. One common question that arises when using chrome://flags is: what determines the "Default" value for each flag? This article delves into the intricacies of how these defaults are set and how they can be influenced.
The initial, or base, "Default" value for a chrome://flag is typically hardcoded within Chromium's source code. Specifically, the about_flags.cc file plays a central role in defining these defaults. This file maps flags to their corresponding functionalities and sets their initial states.
However, this initial setting is not the end of the story.
Peter Kasting, a Chromium developer, explains that while the source code sets a default, this can be dynamically overridden by the field trial code. Field trials are a mechanism used by the Chrome team to test new features on a subset of users before rolling them out to everyone. These trials can toggle flags, effectively changing their "Default" behavior for users included in the experiment.
This dynamic overriding means that the observed "Default" value can vary between different builds and user groups. Local tests might yield unreliable results because builds might fall into different field trials.
A key point of discussion is the difference in "Default" values between developer and official Chrome builds. Suzuki, a Chromium user, noticed that certain flags, like the 'Experimental QUIC protocol,' were enabled by default in Chrome but disabled in Chromium.
Alexei Svitkine, another Chromium developer, clarified that official Chrome builds use the VariationsService to fetch field trial configurations from Google's servers. This service dictates which field trials a particular user (or build) participates in, thus influencing the "Default" values of flags.
In contrast, developer builds, by default, do not fetch these configurations, leading to discrepancies in flag defaults.
The Chromium development community explored whether developer builds could replicate the behavior of official Chrome builds. The consensus is that achieving an exact match is challenging without fetching field trial configurations from Google's servers.
One approach involves setting fieldtrial_testing_like_official_build=1 in GYP_DEFINES before building Chromium. This setting aims to disable activation of field trial tests specified in configuration files, but might not fully replicate official build behavior.
Igor Ianishevskyi raised a specific question about modifying the default value of the kDisableGestureRequirementForMediaPlayback flag. He found that simply changing the SINGLE_DISABLE_VALUE_TYPE macro in about_flags.cc wasn't sufficient.
Greg Thompson suggested looking for calls to CommandLine::HasSwitch(switches::kDisableGestureRequirementForMediaPlayback) within the codebase. This function checks if a specific command-line switch is present, which can override the default behavior.
Ian Clelland pointed out that, for desktop platforms, the feature kCrossOriginMediaPlaybackRequiresUserGesture (defined in content_features.cc) might control the behavior. Overriding this feature might be necessary.
Key Takeaways:
about_flags.cc).about_flags.cc, potentially involving command-line switches or feature overrides.Further Exploration:
chrome://flags and its impact on browser behavior.By understanding these nuances, developers and advanced users can better navigate chrome://flags and effectively experiment with Chrome's experimental features.
