Phone words are displayed as invalid number

[omkolte17]

Plugin version

v24.8.1 but the issue I think persists from v20.0.0. as it is working properly in v19.5.7

Steps to reproduce

1. Select Australia from the country list.
2. Type 1800FLIGHT as the phone number. Even if I enter the equivalent number of 1800FLIGHT which is 1800354448 it also shows as invalid.

Expected behaviour

It should accept the phone number as it is a valid number (checked on libphonenumber). These are called as phone words, more about them here.

Actual behaviour

It shows invalid number.

Initialisation options

utilsScript (loadUtilsOnInit with v24.8.1) and initialCountry

[jackocnr]

Can you describe your use case, for why your users might want to enter their number using phone words?

[omkolte17]

Yes, so I am currently working on a form builder plugin where users can create a form, add various fields and use those forms across their websites. The users had requested the feature regarding phone number field accepting phone words as well. This was initially working when I was using v18.x.x and now I have updated the library and this stopped working.

Also to give you some additional insights, if I use the internal utils function _utilsIsValidNumber() and provide it number using getNumber() or _getFullNumber() it returns true and no validation error is triggered. I explored the codebase a bit and found that the issue may be in the current logic where in case of alphanumeric input the number is split in two parts and validated as two separate entities.
Considering the same example, +611800 and FLIGHT these both return false when validated separately but as a whole they return true using the _utilsIsValidNumber() function. Also the isValidNumber() returns false if I try with the same example just without phone word. So that will be like +611800354448 where 354448 is the conversion of FLIGHT to number.

[jackocnr]

Ok, well as you say, we previously accepted words in numbers as valid, but several people complained about this ("What if a user types an alpha char by accident, it shouldn't say it's a valid number"), and now that we've changed it to reject words in numbers, you're the second person to complain about that, so I think we need an option for this, so people can decide for themselves if they want to allow it or not.

We could call the option allowPhonewords, and I think it would just require adding a check in isValidNumber and isValidNumberPrecise, where we do the alphaCharPosition stuff - probably just change this line:

if (alphaCharPosition > -1) {
to
if (alphaCharPosition > -1 && !this.options.allowPhonewords) {

I don't have time to implement this myself right now, but would be open to a pull request.

[omkolte17]

I see. I think I misunderstood the code a bit. So currently is the if (alphaCharPosition > -1) condition always meant to fail for phone words? I did found it confusing verifying the words and numbers separately and then returning their result but thought there might be some thinking behind it as well.

[jackocnr]

So currently is the if (alphaCharPosition > -1) condition always meant to fail for phone words?

That condition is true if there are any alpha characters in the number (including either phone words, or "ext" extension signifier). Then inside the block, you can see the comment explaining the logic:

Workaround to allow some alpha chars e.g. "+1 (444) 444-4444 ext. 1234" while rejecting others e.g. "+1 (444) 444-FAST". The only legit use of alpha chars is as an extension separator, in which case, the number before it must be valid on its own.

So since we decided to reject phonewords as invalid numbers, but accept numbers that contain extensions (which have the word "ext"), we now split the typed number on the first alpha char, and check that the digits before it are a valid number on their own.