| Commit-Queue | +1 |
Hi Pâris,
Here is the CL I mentioned earlier, would you mind having a look?
I feel that I don't have enough context yet and am not used to work in this part of code, please don't hesitate to be as picky as you want so I can better learn!
Thank you in advance🙏
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
// fetched yet, the first account is returned by default. Returns std::nulloptnot your change but this is not true given
```
AccountPreviewDataService::AccountPreviewPreference
AccountPreviewDataServiceImpl::ComputePreferredAccount() const {
CHECK(base::FeatureList::IsEnabled(
switches::kEnableAccountPreviewPreferredAccount));
// TODO(crbug.com/530144650): Implement heuristic to compute the preferred
// account and preferred data types.
return AccountPreviewPreference();
}
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Auto-Submit | +1 |
// fetched yet, the first account is returned by default. Returns std::nulloptnot your change but this is not true given
```
AccountPreviewDataService::AccountPreviewPreference
AccountPreviewDataServiceImpl::ComputePreferredAccount() const {
CHECK(base::FeatureList::IsEnabled(
switches::kEnableAccountPreviewPreferredAccount));// TODO(crbug.com/530144650): Implement heuristic to compute the preferred
// account and preferred data types.
return AccountPreviewPreference();
}
```
Thanks a lot for the review! 😊
Indeed, the comment was here before the CL, I though it was still the plan even if it's not implemented yet (I guess it makes sense to return the first account to avoid custom handling at the platform UI level to simplify the code, but it can also reduce flexibility in the future if we want to add custom logic at the os level)
Wdyt about leaving it here for now, and update if the implementation changes direction in the future? (re-opening this comment for confirming before submit)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// fetched yet, the first account is returned by default. Returns std::nulloptMenghan Yangnot your change but this is not true given
```
AccountPreviewDataService::AccountPreviewPreference
AccountPreviewDataServiceImpl::ComputePreferredAccount() const {
CHECK(base::FeatureList::IsEnabled(
switches::kEnableAccountPreviewPreferredAccount));// TODO(crbug.com/530144650): Implement heuristic to compute the preferred
// account and preferred data types.
return AccountPreviewPreference();
}
```
Thanks a lot for the review! 😊
Indeed, the comment was here before the CL, I though it was still the plan even if it's not implemented yet (I guess it makes sense to return the first account to avoid custom handling at the platform UI level to simplify the code, but it can also reduce flexibility in the future if we want to add custom logic at the os level)Wdyt about leaving it here for now, and update if the implementation changes direction in the future? (re-opening this comment for confirming before submit)
SGTM
I'll try to keep it mind if we implement UI changes before heuristic changes 😊
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// fetched yet, the first account is returned by default. Returns std::nulloptMenghan Yangnot your change but this is not true given
```
AccountPreviewDataService::AccountPreviewPreference
AccountPreviewDataServiceImpl::ComputePreferredAccount() const {
CHECK(base::FeatureList::IsEnabled(
switches::kEnableAccountPreviewPreferredAccount));// TODO(crbug.com/530144650): Implement heuristic to compute the preferred
// account and preferred data types.
return AccountPreviewPreference();
}
```
Pâris MeulemanThanks a lot for the review! 😊
Indeed, the comment was here before the CL, I though it was still the plan even if it's not implemented yet (I guess it makes sense to return the first account to avoid custom handling at the platform UI level to simplify the code, but it can also reduce flexibility in the future if we want to add custom logic at the os level)Wdyt about leaving it here for now, and update if the implementation changes direction in the future? (re-opening this comment for confirming before submit)
SGTM
I'll try to keep it mind if we implement UI changes before heuristic changes 😊
| 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. |
[Signin][SAS] Return std::optional from GetPreferredAccountForPromo
Previously, GetPreferredAccountForPromo always returns a non-null
preference object event if the gaiaID string is not valid. This can be
confusing (preferred data types list is not meaningful if the preferred
account ID is not valid) and complexifies slightly the data conversion
from native to java, which forbid conversion when the ID string is empty
[1].
This CL updates AccountPreviewDataService::GetPreferredAccountForPromo
to return std::optional<AccountPreviewPreference> when necessary (e.g.
no account on the device) or if the saved/computed gaia_id is not valid.
If we realise that we prefer that the service shouldn't be called in
cases when it can return null, we can remove the `optional` from the
return type later.
[1]
https://source.chromium.org/chromium/chromium/src/+/main:google_apis/gaia/gaia_id.cc;l=36;drc=60df9044934a2841875904f21e9673afe970da1e
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |