return isEnabled("PrewarmZeroSuggestTrigger");maybe `isEnabled("Prewarm") && isEnabled("PrewarmZeroSuggestTrigger");` just in case.
return isEnabled("Prewarm");`isEnabled("Prewarm") && !isEnabled("PrewarmZeroSuggestTrigger");`
Otherwise, both mode may be enabled together for the zero suggest settiong?
(but IIUC, these two methods are added to follow the guideline, but were not used at all?)
base::FeatureList::IsEnabled(features::kPrewarmZeroSuggestTrigger)) {I'm a bit confused on the original code. Do you remember why we need this parameter check here?
It seems this gate should be required always regardless of the trigger type.
CHECK(features::kPrewarmUserInteractionTrigger.Get());We would keep this as `CHECK(!ase::FeatureList::IsEnabled(features::kPrewarmZeroSuggestTrigger));`?
if (base::FeatureList::IsEnabled(features::kPrewarmZeroSuggestTrigger)) {Should we keep the base kPrewarm check too? Theoretically they may be configured differently, and need a check here to avoid CHECK failures.
if (base::FeatureList::IsEnabled(features::kPrewarm)) {Similarly !base... check too.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
base::FeatureList::IsEnabled(features::kPrewarmZeroSuggestTrigger)) {I'm a bit confused on the original code. Do you remember why we need this parameter check here?
It seems this gate should be required always regardless of the trigger type.
Checked the code and it seems that we missed to add `kPrewarmUserInteractionTrigger` to the if clause when adding the feature parameter. Yes this should always be checked.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
maybe `isEnabled("Prewarm") && isEnabled("PrewarmZeroSuggestTrigger");` just in case.
Done
`isEnabled("Prewarm") && !isEnabled("PrewarmZeroSuggestTrigger");`
Otherwise, both mode may be enabled together for the zero suggest settiong?
(but IIUC, these two methods are added to follow the guideline, but were not used at all?)
Done
base::FeatureList::IsEnabled(features::kPrewarmZeroSuggestTrigger)) {Jiacheng GuoI'm a bit confused on the original code. Do you remember why we need this parameter check here?
It seems this gate should be required always regardless of the trigger type.
Checked the code and it seems that we missed to add `kPrewarmUserInteractionTrigger` to the if clause when adding the feature parameter. Yes this should always be checked.
Done
if (base::FeatureList::IsEnabled(features::kPrewarmZeroSuggestTrigger)) {Should we keep the base kPrewarm check too? Theoretically they may be configured differently, and need a check here to avoid CHECK failures.
Done
if (base::FeatureList::IsEnabled(features::kPrewarm)) {Jiacheng GuoSimilarly !base... check too.
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
CHECK(features::kPrewarmUserInteractionTrigger.Get());We would keep this as `CHECK(!ase::FeatureList::IsEnabled(features::kPrewarmZeroSuggestTrigger));`?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
lgtm
// Set default search provider to match features::kPrewarmUrl.nit, wrap comment symbols in ticks
// ... `kPre`.
TemplateURLData template_url_data;missing include components/search_engines/template_url_data.h
ScopedPrewarmFeatureList::ScopedPrewarmFeatureList(PrewarmState state) {optional nit, if this file is only for testing, consider adding some test_ or testing_ affix to the filename
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
ScopedPrewarmFeatureList::ScopedPrewarmFeatureList(PrewarmState state) {optional nit, if this file is only for testing, consider adding some test_ or testing_ affix to the filename
Added a TODO linking to a clean-up bug (crbug.com/533212496) to rename this file later.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// Set default search provider to match features::kPrewarmUrl.nit, wrap comment symbols in ticks
// ... `kPre`.
Done
TemplateURLData template_url_data;Jiacheng Guomissing include components/search_engines/template_url_data.h
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
base::FeatureList::IsEnabled(features::kPrewarmZeroSuggestTrigger)) {Jiacheng GuoI'm a bit confused on the original code. Do you remember why we need this parameter check here?
It seems this gate should be required always regardless of the trigger type.
Jiacheng GuoChecked the code and it seems that we missed to add `kPrewarmUserInteractionTrigger` to the if clause when adding the feature parameter. Yes this should always be checked.
Done
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
4 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: chrome/browser/preloading/prerender/prerender_manager_unittest.cc
Insertions: 3, Deletions: 3.
The diff is too large to show. Please review the diff.
```
Split the kPrewarmZeroSuggestTrigger feature param into a separate feature.
The CL cleans up the prewarm trigger feature parameters.
The kPrewarmZeroSuggestTrigger feature param is moved into a separate
feature (PrewarmZeroSuggestTrigger) to test it in a follow-up
experiment. The kPrewarmUserInteractionTrigger feature param is removed.
The CL also cleans up the filed trial testing config of DSEPrewarm.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |