-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
isValidNumber() passing on invalid number #1535
Comments
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. |
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! |
Thanks for raising this. I can confirm that The quick fix is to switch to 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: 0740 - is possible number (local only) +447400 - is possible number (local only) 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 |
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 |
The below screenshot is from the Wikipedia page for Telephone numbers in the United Kingdom shows that there are valid UK numbers (after the leading 0) of length 7, 9 and 10. (It also shows valid numbers of shorter lengths e.g. dialing "999" for emergency services, but I think libphonenumber excludes numbers like those) So in this case, we would have to find a way to exclude 08 (toll free) numbers lengths from the validation. Perhaps we only want to include mobile numbers? I think that would be fine for most use cases. So I'll look into this next. Ideally we'd find a way to exclude all the meta data for other number types, to reduce the bundle size, but I don't know if this is possible - I'll ask on the LPN discussion thread, linked above. |
Ok I'm going to re-open this issue, as I've found a way to move forwards, but don't have time to implement it right now. In utils.js, in the |
Hi, I think the last comment hits the nail on the head. For the UK, mobile numbers can be 07 or +44 if using the international prefix. For example: 07111 012345 = +447111 012345 01 numbers will be a landline of a residence or business. I've never actually heard of a 7-digit number, it looks like they are newer toll-free options. I think the |
Just noting here that LPN have said there is no way to include/exclude the metadata for specific number types unfortunately. |
|
Unfortunately, I am still seeing the original issue, when called |
I'm confused, the original issue was about isValidNumber returning true for invalid numbers, but the two number examples you just shared are valid, no? |
Those two numbers are valid, but |
That's strange, I can't reproduce that on the validation demo - if I select GB and enter "07123 01" and click Validate it says "Invalid number". (Note that this demo is using v20.0.5, where mobileOnly is true by default, so no need to pass true to isValidNumber). Can you make sure you're using the latest version? |
My bad… The JS and CSS was updated, but the utils script was not! Now it’s working as expected. Sorry!
… On 21 Mar 2024, at 13:03, jackocnr ***@***.***> wrote:
That's strange, I can't reproduce that on the validation demo <https://intl-tel-input.com/examples/validation-practical.html> - if I select GB and enter "07123 01" and click Validate it says "Invalid number". (Note that this demo is using v20.0.5, where mobileOnly is true by default, so no need to pass true to isValidNumber). Can you make sure you're using the latest version?
—
Reply to this email directly, view it on GitHub <#1535 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF5SPASJYZW7H6Z6NFBCGPLYZLLANAVCNFSM6AAAAABD33P572VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJSGI2DANBTGA>.
You are receiving this because you authored the thread.
|
Steps to reproduce
which focuses the confirm button at length = 7 instead of the full length number for the UK.
Expected behaviour
Should only pass after 11 digits (ie, 07123 012345) or 10 digits if the number begins +44 +447123 012345
Actual behaviour
isValidNumber() is passing when length is 7 for UK format numbers
Initialisation options
The text was updated successfully, but these errors were encountered: