You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When switching countries, at vue-tel-input-vuetify.vue#571, the code incorrectly uses the .national version of the phone number rather than the .significant version. There is no sensible scenario, when switching countries, where we would want to preserve the local-dialing prefix that is included in the .national version of the phone number. This bug is inherited from upstream, and I have filed a bug there as well.
Repeat by:
Select Algeria as your country, and enter the awesome-phonenumber example phone number, which is +355 22 345 678.
Change the country to USA.
Observe that you get an area code starting with a '0', which is an illegal area code under the NANPA rules.
What has happened is that the leading zero added for local dialing in Algeria has been added to the number because .national was used rather than .significant.
Expected behavior
Expected behavior is that the leading zero that is only significant for in-nation dialing within Algeria does not contaminate the phone number after switching countries.
The use-case is that the user has started keying a phone number, realizes that they have the wrong country selected, and changes the country drop-down to select the intended country. This should not alter the numbers they have typed.
Versions
Problem observed in v1.2.11, but since this looks to be inherited from up-stream, I suspect it's a long-term issue.
Environment:
Problem is environment-independent.
Recommended Fix
The recommended fix is to change the code to use .significant rather than .national. Note that in all cases where .national has been set, .significant has also been set.
The text was updated successfully, but these errors were encountered:
Current behavior
When switching countries, at vue-tel-input-vuetify.vue#571, the code incorrectly uses the .national version of the phone number rather than the .significant version. There is no sensible scenario, when switching countries, where we would want to preserve the local-dialing prefix that is included in the
.national
version of the phone number. This bug is inherited from upstream, and I have filed a bug there as well.Repeat by:
What has happened is that the leading zero added for local dialing in Algeria has been added to the number because
.national
was used rather than.significant
.Expected behavior
Expected behavior is that the leading zero that is only significant for in-nation dialing within Algeria does not contaminate the phone number after switching countries.
The use-case is that the user has started keying a phone number, realizes that they have the wrong country selected, and changes the country drop-down to select the intended country. This should not alter the numbers they have typed.
Versions
Problem observed in v1.2.11, but since this looks to be inherited from up-stream, I suspect it's a long-term issue.
Environment:
Problem is environment-independent.
Recommended Fix
The recommended fix is to change the code to use
.significant
rather than.national
. Note that in all cases where.national
has been set,.significant
has also been set.The text was updated successfully, but these errors were encountered: