Our phone number is formatted by using PhoneNumberFormattingTextWatcher from Android. It uses current system locale.

It displays as "+1 (555) 555-5555" if type in "+15555555555".
It displays as "1 555-555-5555" if type in "15555555555".
It gives up formatting if type in "+1(555)5555555" (displays "+1(555)5555555)").

So we might just have to remove parentheses from out data as the beginning, WDYT?
 

The contact and shipping sections don't use the text watcher. They show the phone number as-is from the autofill table. That display needs fixing. +Seb for guidance, because he has some background.

Can you try that with a valid German phone number on your phone? I'm curious to see how it will handle a format that do not correspond to the phone's locale.

As to your question, your first proposition is the one that is valid based on the E.123 standard. If I understand correctly, you would have to make sure that the phone number contains the country code. Can you also try to see how it gets formatted if it's not present?

Reply comment #4

It works well with '+' character for international phone number, for example, it displays "+86 10 6250 3000" when typing "+861062503000" (give up format without '+').

For how it gets formatted, I did not read the code in detail, but you can find it in chromium code search (PhoneNumberFormattingTextWatcher.java).

Reply comment #3

My proposal to remove parentheses from the phone number and save it to autofill seems not good since there might have good reason not do that in Android PhoneNumberUtils. I could format phone number before display it and make autofill and payment request editors use the same phone number formatter for now as this bug intend.

But, ideally, I think we could have all phone numbers in autofill database have been formatted with the same formatter across platforms so as to display them without extra effort. is there any reason not do that?

I agree with your comment about consistency across platforms. So maybe using libphonenumber as a formatter would be better, since all platforms could use it. 

For you proposition to save if formatted in the DB, I have to think and maybe talk to RogerM too. Since that data may come from Autofill, I'd have to check if there are problems there.

FYI, 

We currently stores formatted phone numbers instead of raw user inputs in payment request address and contact editor to profiles (I guess these information also can be used by Autofill).

We do not format phone number and save the raw user inputs in Autofill editor.

Interesting, thanks for mentioning.

+rogerm: see c#7.

Do you think we should do the same thing for Autofill?

assign to myself for now

Storing as pre-formatted strings seems reasonable.

Autofill parses the stored phone number and uses the parsed phone number data to actually perform fills, so storing the data pre-formatted is fine. 

Thanks,

Then, I suggest we store formatted phone numbers instead of raw user inputs so that they can be presented without extra efforts across platforms. 

To achieve that, first, we need to migrate existing phone numbers in Autofill; second, we should make sure new phone numbers are formatted correctly in the same way.

I don't know how difficult to do the first task. For the second task, I think we could have a shared formatter for all entry points on different platforms. Create a thin wrapper class on top of libphonenumber might be a good choice as sebsg@ mentioned.

Any ideas or objection?

The logic in phone_number.cc [1] seems straightforward, but there might be some gotchas. Before doing a wholesale change of all stored numbers, you could try changing phone numbers in your local Web Data SQL database (use SQLite browser for this) and see if it behaves.

Also, it seems like phone_number.cc takes care of some of your concerns because it contains |cached_phone_number_| which is formatted so it's at most one per number-profile combination.

[1] https://cs.chromium.org/chromium/src/components/autofill/core/browser/phone_number.cc?sq=package:chromium&dr=CSs&l=93

gogerald@, if you are interested in this project do you want to write a short design brief on the possible routes to take here? Whether it's changing the accessor methods to support E.123, or rewriting the values in the DB, I think it will be useful for everyone to have an idea of the complexity.

Prepared a very simple doc for communication as request, please take a look, https://docs.google.com/a/google.com/document/d/1H8U486cj5Y1gyWObWToyIp_v50LK01rA5UPBu3yqENY/edit?usp=sharing

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7cede91629178ab5ac464e86323f17c24a522295

commit 7cede91629178ab5ac464e86323f17c24a522295
Author: gogerald <gogerald@chromium.org>
Date: Tue Mar 14 23:53:40 2017

Format and validate phone number by using libphonenumber

Refer details on bug and
https://docs.google.com/a/google.com/document/d/1H8U486cj5Y1gyWObWToyIp_v50LK01rA5UPBu3yqENY

BUG= 689046 

Review-Url: https://codereview.chromium.org/2743763003
Cr-Commit-Position: refs/heads/master@{#456897}

[add] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/java/src/org/chromium/chrome/browser/autofill/PhoneNumberUtil.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/java/src/org/chromium/chrome/browser/payments/AddressEditor.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/java/src/org/chromium/chrome/browser/payments/ui/EditorView.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/java_sources.gni
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestBillingAddressTest.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestDynamicShippingSingleAddressTest.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestFreeShippingTest.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestIncompleteContactDetailsAndFreeShippingTest.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestJourneyLoggerTest.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestMetricsTest.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestNoShippingTest.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/android/javatests/src/org/chromium/chrome/browser/payments/PaymentRequestShippingAddressTest.java
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/browser/BUILD.gn
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/browser/android/chrome_jni_registrar.cc
[modify] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/browser/autofill/android/DEPS
[add] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/browser/autofill/android/phone_number_util_android.cc
[add] https://crrev.com/7cede91629178ab5ac464e86323f17c24a522295/chrome/browser/autofill/android/phone_number_util_android.h