isValidNumber() passing on invalid number about intl-tel-input HOT 14 CLOSED

Thanks for raising this. I can confirm that isValidNumber is incorrectly returning true for UK numbers of 7-10 digits (as you say it should only be true for UK numbers of 11 digits). I think this is because technically, in the UK, you can dial local numbers of 7 digits and they work fine. But obviously, that is not useful for us in this context.

The quick fix is to switch to isValidNumberPrecise which should work as expected. You can check the readme for more info on the difference between these two methods.

I will explore this issue further with libphonenumber, the lib we use for validation, and see if we can find a way to fix it. So I'll leave this issue open for now.

UPDATE: I've asked the question on the libphonenumber discussion group here: https://groups.google.com/g/libphonenumber-discuss/c/H-VVzK0AArM

Some test results from libphonenumber below:
(NOTE that our isValidNumber actually uses their isPossibleNumber)

0740 - is possible number (local only)
07400 - is possible number (local only)
074001 - is possible number (local only)
0740012 - is possible number
07400123 - is possible number
074001234 - is possible number
0740012345 - is possible number
07400123456 - is possible number (this is actually a valid number)

+447400 - is possible number (local only)
+4474001 - is possible number (local only)
+44740012 - is possible number (local only)
+447400123 - is possible number
+4474001234 - is possible number (local only)
+44740012345 - is possible number
+447400123456 - is possible number (this is actually a valid number)

We are able to filter out the local-only numbers and mark them as invalid, but the problem is that libphonenumber isn't consistently marking them as local-only. So either this is a bug with LPN, which is unlikely, or maybe there's another way to check if they're local only (which I've asked in the discussion), or else maybe there's a way to simplify the metadata so it only includes patterns that are relevant to mobile numbers.

Failing that, it would actually be fairly straightforward to add some custom code here, which says if it's a GB number, then check its 11 digits (while also handling the possibility of +44, or the use of separateDialCode etc). Though I wonder if this issue applies to any other countries as well...

from intl-tel-input.

We use libphonenumber for formatting, validation and generating placeholder numbers - if your issue relates to one of these things, please check their test site first and if you see the problem there please file an issue with them instead.

If it's working correctly in libphonenumber, the next step is to check that we're using the latest version of libphonenumber in the plugin - check the version history here. If we need to upgrade, it only takes 5 minutes to do this yourself and submit a Pull Request - instructions here: Updating to a new version of libphonenumber.

from intl-tel-input.

Hi,

Thanks for this, tests pass correctly on the test site, and I've just pulled the latest update files and tested again and the problem would appear to persist!

from intl-tel-input.

I think it's unlikely we will get any help from LPN any time soon, so I've added a workaround for this for now, which fixes isValidNumber for UK mobile numbers at least. Released in v19.5.5.

from intl-tel-input.