Domain Registration: Italian Phone Number Validation

[zdenys]

A short summary of the problem

While registering a new domain, the phone number field in the Domain Registration Information section would not accept a phone number starting with 39. This is because +39 is the phone code for Italy and hence, every time I tried to type 39 it was interpreted (I suspect) as the country code and just deleted right away. I tried to put other digits instead of 39 (like 33) and then change them back to 39 once I typed the whole number, but with no success. The initial 39 gets wiped out automatically without a way for me to put in my real phone number.

Note 1: The issue can be reproduced when signing up for a new WordPress.com account with a paid plan and registering a new domain all at once.

Note 2: I could not reproduce the issue when registering a domain on a previously registered account, as contact information gets pre-filled from WordPress.com profile and I can edit the phone number to be +39 39X XXX XXXX with no problem. Also, in this case, the Domain Contact Information section looks different from the case in Note 1 (where it has a Designated Agent disclaimer and a checkbox similar to the ones here https://en.support.wordpress.com/domains/designated-agent/).

The steps needed to reproduce the problem

Follow the steps 1 through 6 to register a new domain as described here https://en.support.wordpress.com/domains/register-domain/#instructions-for-registering-a-new-domain. The issue happens at step 7.

Context & links

In Italy, phone numbers starting with 39 all belong to the mobile operator Tre Italia aka 3 aka H3G (11% market share as of end 2016) (MNO section here https://it.wikipedia.org/wiki/Prefissi_telefonici_dei_cellulari_italiani). So while it is true that these numbers are not so many and registrants would rather use landline phone numbers, other Italian users may still encounter the described issue.

Any ideas you have on how to resolve the issue

I suspect there is a validation rule behind it. It needs to be changed to account for the situation where there is a country code +39 followed by another 39 (part of the phone number).

[designsimply]

Note: sounds similar-ish to #21862 and #23276 (problems with phone number validation in 2FA).

[designsimply]

I was unable to reproduce the problem using the following testing steps:

1. Clear browser cache and cookies.
2. Go to https://wordpress.com/
3. Click "Get Started."
4. Click "Continue."
5. Select a custom domain.
6. Fill in account details and continue to the checkout page.
7. In the phone number field type in any Italian phone number starting with "+39 39"
8. Check for any phone validation problems that might prevent the form from going forward.

Sample phone numbers I tested:

• +39 393 900 3227
• +39 39 325825
• +39 39 394641

Result: I am able to enter any of the sample numbers above either by typing them in directly or by copy/paste and they seem to work normally.

Video: 24s ^{Tested with Firefox 60.0.1 on macOS 10.13.4.}

^{Seen at https://wordpress.com/checkout/madefortesting4048com.wordpress.com using Firefox 60.0.1 on macOS 10.13.4.}

Questions:

• Are my testing steps correct?
• Does the problem happen just after typing in the number or only after filling out the form completely and then clicking the "Continue to Checkout" button?
• Are you copying and pasting or typing in the phone number directly?
• Can you verify how many digits the phone number you are using has or provide the number or a slightly modified version of the number?
• Does it work if you put a leading 0 before the 2nd 39, i.e. +39 039? #
• What OS and browser versions are you testing with?

[zdenys]

Thank you so much for looking into this! Here I report what I found and answer your questions along the way:

I did another test by creating a new account and choosing a Personal plan with Domain Registration (just like you did, so your steps are correct). I also confirm that the Order Summary screen is identical in my case. I tried to type in many numbers like this +39 39X XXX XXXX and this +39 XXX XXX XXXX and it worked every time (as it did for you too).

Then I tried to omit +39 and type in only the phone number and that's where the issue is! As soon as I type in 39, it gets cancelled out. I tried copying and pasting too, it cancels out the initial 39 anyway. It works with all other initial combinations 3X (X can be any digit from 0 to 8) except for 39. Italian phone numbers all have 10 digits (excluding the country code).

Going back to when I first encountered this issue, this is what likely happened. Since in Italy the +39 code is almost never used and since the Phone field has the nice Italian flag (that I took as a sign that my number will be recognized as Italian without the country code), I likely only tried to type in my number without the +39 code. And that's when I was unable to do so. I could not remember this clearly until now that I've done another test. Sorry for leading you off the path.

OS & Browser: Windows 10 & Chrome 66

In the below animation, I use 3911711711 as my number and try all the actions mentioned above (typing 39, typing all other 3X combinations, pasting, pasting 3X11711711 and then changing X to 9).

[ramonjd]

This seems to happen whenever you try to input two numbers which match the dialling prefix of the country. So if you change the country to Australia (+61) and then type 61 into an empty field, I'm assuming the pattern matcher treats these numbers as a prefix, and removes them.

@umurkontaci might be the best person to comment. There are few layers of code involved in this phone number validation.

[KokkieH]

We've had another report of this via the support forums, with a twist - if you select a locale that has a dialing code starting with 1-, the form automatically switches the country to US as the number is typed (US dialing code is +1)

To replicate

1. Go through the flow to add a new domain
2. On the contact information screen, select Saint Vincent and the Grenadines as the country for the phone number.
3. Start typing in the number

What happens

The flag anything added after the country code causes the flag to automatically change to US, and the 784 part of the country code just falls away. If I delete the number and start retyping, the VC flag reappears as I type the country code, but then again reverts to US as the rest of the number is added.

Attempting to paste in the number doesn't work either - the 784 is stripped out, the flag switches to US, and the remaining digits are arranged in the US format with an error that the number is too short.

I was also able to replicate this with other locales which has a country dialing code that starts with 1: Trinidad and Tobago (TT), British Virgin Islands (VG), Turks and Caicos Islands (TC), Montserrat (MS), Northern Mariana Islands (MP), and Saint Lucia (LC). (There are more countries that follow this pattern, but I think its safe to assume all are affected.)

While looking through the list of country codes in the source code I also noticed that Saint Martin (MF) is not listed in the country drop-down at all, and typing the country code for that locale, 1-599, just has the number treated like a US phone number from the start.

[ramonjd]

@KokkieH

Thanks for this!

Though the intention behind phone number validation was sound, I'm wondering if we're trying to be too clever with this field. Clearly it's getting in the way of users, who, we should probably trust, know their own phone numbers.

I'm going to go out on a limb here and say that the flags are redundant. In this field, we care about country prefixes and the phone numbers that follow them. The flags add a technical and, arguably, political layer of complexity.

We could still check for valid country prefixes, and, if a country doesn't exist, such as in the case of Saint Martin, fallback to a general regex.

Any other ideas?

@Automattic/i18n

Edit: After reflection, I might soften my statement and recognize that flags might be useful to those who may not necessarily know the country prefix offhand. An alternative might then be to let the flag select control determine the prefix, and remove the validation for the prefix from the phone number field, permitting the user to worry about domestic area codes.

[KokkieH]

An alternative might then be to let the flag select control determine the prefix, and remove the validation for the prefix from the phone number field, permitting the user to worry about domestic area codes.

This could work. Probably some messaging that one should not also include the country code in the number field would be good. And then I just wonder how we'd handle a case like St Martin that's not in the country drop-down.

[ramonjd]

And then I just wonder how we'd handle a case like St Martin that's not in the country drop-down.

Good point. I'm just pulling these out of my beanie, but we could:

1. add missing countries to the list (the known knowns)
2. add an 'Other' option to the drop down that would insert a + into the phone field, indicating to the user that they can add the missing prefix themselves.
3. remove the requirement for a country code altogether (the dodgiest option)

[folletto]

Taking a step back for a moment: it seems there's an issue with the detector that is detecting "39" instead of "0039" or "+39" (and all other country codes).

In other words: it seems the code is getting the detection backwards, as it should be detecting "+39" but not "39" (currently it seems detecting both in updating the dropdown, but just one gets removed), while from the above issues listed it seems doing almost the exact opposite.

I'd suggest to first fix this, before expanding the scope of this issue to update the form in other ways (and open a separate issue for that, if we think it's a good idea).

[jamiepalatnik]

Just wanted to add another report here in #6802237-hc. The user was from Norway and had a phone number beginning with 47, the same as the country code. I was able to reproduce when I type only the phone number starting with 47—the 47 gets erased. As mentioned above, I am able to type the full number if I also add +47 first.

[ramonjd]

The fact that people are having trouble with this makes me think that an A/B is in order, where we at least simplify the input masking. The logic is defeating UX. Seeing my input vanish or change before my eyes is enough to make me think twice about a purchase, so I'd speculate that it could be turning some other people off too (especially those who don't report it to support).

Do we really want to bundle, let alone maintain 6,375-lines of the world's phone patterns that we use for one field, for one purpose?

I guess it depends on how crucial the patten-matching is for our domains registration. @Automattic/cobalt will know the answer to that.

[aidvu]

I think the list is autogenerated on build. As for maintenance, we haven't really touched that field much, since it's inception. It is hardish to maintain. As for the UX, it actually significantly lowered the # of errors we got for domain registrations because of bad phone numbers.

[stale[bot]]

This issue has been marked as stale and will be closed in seven days. This happened because:

• It has been inactive in the past 9 months.
• It isn't a project or a milestone, and hasn’t been labeled `[Pri] Blocker`, `[Pri] High`, `[Status] Keep Open`, or `OSS Citizen`.

You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation.

[KokkieH]

Checked and this is still an issue

[stale[bot]]

This issue has been marked as stale and will be closed in seven days. This happened because:

• It has been inactive in the past 9 months.
• It isn't a project or a milestone, and hasn’t been labeled `[Pri] Blocker`, `[Pri] High`, `[Status] Keep Open`, or `OSS Citizen`.

You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation.

[aisajib]

I have a user who reported this issue on #3428496-zen and I was able to replicate it. They had an Indian phone number that started with 91 without the country code. But the form was removing that 91 thinking the user was entering the country code again. As a result, the user was unable to enter their phone number that starts with 91.

I'm reopening the issue.

[lsl]

Something for @Automattic/i18n to look into? I would suggest showing the country phone code next to the flag, remove the magic rewriting and just do a plain valid/invalid check.

Phone number validation is a very hard problem and changes over time, I would prefer to remove this validation completely using freeform but I believe there are domain registration requirements that phone numbers conform to some spec / are valid. This requirement is server side but the best place for validation was decided to be upfront in the client.

[klimeryk]

Correct, this component was introduced a few years ago to alleviate some issues that users had when submitting their contact information. The format that registries usually expect is +123.4567890. . is the separator for the country code. However, that's not how most (all?) users write their phone number. Throw in other inconsistencies (spaces, dashes, parenthesis) and it's hard to predict how it should be properly formatted. The idea was that we try to show phone number in a country-specific way, so that the user can be most comfortable with it.

Unfortunately, as it usually is with components that try too hard, when you push it, it leads to worse user experience. As a result, I'm also not a fan of the current implementation - but not sure what would be the better iteration here. I'm very open to suggestions - maybe there are now new, mature options that we could simply plug in here, instead of trying to franknestein it ourselves (FWIW, we do use IIRC Google's libraries for phone number parsing, etc.).

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[synora]

Tested this and it's still occurring. Removed Stale label.

[leonardost]

This was hopefully fixed by #54477. 🙂