Feature switches should automatically control origin trial |
|||
Issue descriptionFeature implementations can use a base::Feature switch to allow remote disabling (i.e. via Finch). However, the feature can be re-enabled on the Blink side by an origin trial. See this thread for context: https://groups.google.com/a/chromium.org/d/msg/experimentation-dev/k6ZdmFp84QE/ASTx3hB0BQAJ We should have a mechanism to link a base::Feature with the corresponding origin trial, so that features are enabled/disabled appropriately on the Blink side.
,
Jul 24 2017
,
Jul 24 2017
Do you have additional detail on what you mean by linking the feature and trial? The example in the thread makes sense concretely: unless the base::feature for webusb is turned on at the command line, the WebRuntimeFeature will be disabled, and only enabled via OriginTrials. This doesn't seem like a blanket rule for all of the features there.
,
Jul 26 2017
Discussed offline, the initial approach/solution is: - Define a mapping between origin trial and base::Feature. TBD, but could be in a hand-edited class, or extension to code-generation based on RuntimeEnabledFeatures.json5 - When origin trials tokens are validated, check if there is an associated base::Feature which has been disabled. If so, do not enable the origin trial. i.e. enhance the existing code path that looks for trials that have been disabled.
,
Dec 12 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by cha...@chromium.org
, Mar 31 2017