commit 207b63b58838b3e99fd49f4fce68fcba581b51bb
author Florian Leimgruber <fleimgruber@google.com> Mon Sep 26 15:48:04 2022
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Mon Sep 26 15:48:04 2022
tree 69f5f33c1c1059edeaf795835eb0eefe9d84ed71
parent b98fa4c88e468d22e4285a5f1d18d306be68ae1d

Fix incorrectly deduced region for phone number parsing.

We mistakenly assumed calling AutofillCountry::CountryCodeForLocale()
with a 2 letter country code would return that country code. It was now
discovered that this can lead to strange mappings like BE (Belgium) ->
BY (Belarius), CA (Canada) -> ES (Spain), and many others.

This was caught by the ConsiderVariationCountryCodeForPhoneNumbers
experiment. As the name suggest, the idea of this feature was to give
the variation country code precedence over the app locale when parsing
phone numbers. This CL fixes the feature to do just that. The high level
approach is as follows:

On import, multiple post-processing steps happen, in this order:
- Setting the phone number
- Multi-step imports
- Complementing the country
By cyclic shifting these 3 steps, we can make sure that the country
is complemented when the phone number is parsed. Because the phone
number parsing logic defaults to the profiles country first, this makes
sure that the variation country code takes precedence.
For details see the design doc linked in Comment 11 of the bug.

Bug: 1287498
Change-Id: Ic41dc7da6fbe02b5ba022f53607c45826f916067
Fixed: 1296077
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3858177
Reviewed-by: Vidhan Jain <vidhanj@google.com>
Reviewed-by: Dominic Battré <battre@chromium.org>
Commit-Queue: Florian Leimgruber <fleimgruber@google.com>
Cr-Commit-Position: refs/heads/main@{#1051214}