Partial Formatter with "US" default region breaks for phone numbers starting with "3" about phonenumberkit

[Brandon-P]

Thanks @katherinemarsh for highlighting these repo steps. We are currently experiencing the same issue in our implementation. We found this issue after investigating a parsing issue in a previous release of PhoneNumberKit that causes some users to be unable to edit their profile information. Updating to the most current release would resolve our existing issue but exposes this issue you reported, which would prevent a substantial portion of our userbase from logging in with their phone number.

An additional piece of information to share is that we found that verifying in simulator is not sufficient as the issue was not reproducible in simulator but reproduced when built to device.

[BrentMifsud]

I found a temporary workaround here.

You need to make sure you strip out all (, ), , and - before calling formatPartial.

If the partial formatter picks up a number in the broken format: (3 the partial formatter just returns the raw value you pass in.

So on our end, as the user types values, we strip out the applied formatting before requesting a new value from PhoneNumberKit.

[bguidolim]

Thank for reporting that. I can take a look at it, however only after 2 to 3 weeks since I'm don't have access to my computer in that period.
Or if you fix that and open a PR, I will be glad to review it.

[BrentMifsud]

seeing this as well.

can confirm its with all +1 country codes (Canada, US, etc...)

[katherinemarsh]

I found this issue began with this metadata update: ddbc873, yet the issue doesn't exist in https://github.com/google/libphonenumber. I see the metadata on this library is updated frequently to match the libphonenumber metadata, so it's not that specific metadata version causing the issue

[BrentMifsud]

seems the problem is numbers beginning with 3 are not matching this leading numbers regex: [24-9]|3(?:[02-9]|1[1-9]) and getting the wrong number formatter.

My domain knowledge about phone number validation is quite limited, so I don't know if the problem is with the regex itself or not.

Another issue I have noticed is that if you continue typing out the phone number, it never receives the trailing ) after the area code.

So you end up with a number formatted like so: (3333333333

[nickrkeller]

First off, wanted to thank @BrentMifsud for the workaround!

However, after trying it out in our app, we were still unable to resolve our issues.

Just commenting here to boost awareness again for any contributors -- any help would be greatly appreciated!

[bguidolim]

Hey folks!
Do you mind checking if the branch of PR #727 fixes the issue?