Fix bug in X-Mask where user input that matched the non wildcard value were being stripped #4253
Conversation
| @@ -137,7 +137,7 @@ export function stripDown(template, input) { | |||
| } | |||
|
|
|||
| for (let j = 0; j < inputToBeStripped.length; j++) { | |||
| if (inputToBeStripped[j] === template[i]) { | |||
| if (inputToBeStripped[j] === template[i] && template[i] !== inputToBeStripped[i]) { | |||
There was a problem hiding this comment.
This can never evaluate to true.
It's saying "if these match and if they also don't match" which is impossible.
There was a problem hiding this comment.
Hi @ekwoka - Thanks for the quick feedback.
I disagree, note that the new conditional is not using the same iterator for inputToBeStripped (we are using i not j)
From mask.spec.js:L11
expect(stripDown('(999) 999-9999', '716 2256108')).toEqual('7162256108')
template = "(999) 999-9999"
input = "716 2256108"
// when i = 5 and j = 3 we see inputToBeStripped[j] = " " and template[i] = " " (so first condition match),
// then we see inputToBeStripped[i] = 2,
// This matches the condition the space is removed.There was a problem hiding this comment.
Ah yes, you're right. That's hard to read.
|
There isn't actually a bug. It was behaving as expected. But this actually breaks behavior, but seemingly there weren't appropriate tests to catch that breakage. |
| @@ -11,6 +11,8 @@ test('strip-down functionality', async () => { | |||
| expect(stripDown('(999) 999-9999', '716 2256108')).toEqual('7162256108') | |||
| expect(stripDown('(999) 999-9999', '(716) 2256108')).toEqual('7162256108') | |||
| expect(stripDown('(999) 999-9999', '(716) 2-25--6108')).toEqual('7162256108') | |||
| expect(stripDown('+1 (999) 999-9999', '7162256108')).toEqual('7162256108') | |||
There was a problem hiding this comment.
| expect(stripDown('+1 (999) 999-9999', '7162256108')).toEqual('7162256108') | |
| expect(stripDown('+1 (999) 999-9999', '+1 (716) 225-6108')).toEqual('7162256108') |
this would be a more accurate test to what you wanted to "fix". Which will likely fail, outputting 1716225610
There was a problem hiding this comment.
Yes you are correct that this solution does not handle that latter case, I think both your suggestion and what I introduced would be good introductions to the spec and would mimic behavior of other masking tools (e.g. maska https://codepen.io/Robert-Marney/pen/LYoLVRb)
In the pen above you can see the mask which is equivalent to the test case can handle both types of user input (e.g. a direct mask format as well as the numbers represented by the wildcard fields)
There was a problem hiding this comment.
Just to clarify, which bug qre you trying to fix here? The example you posted (maska) behaves exactly as x-mask.
If you type 1, this generates +1 and not +1 (1.
There was a problem hiding this comment.
@SimoTod - The bug is the application of autocomplete values
There was a problem hiding this comment.
Ok, that is the first time you mention it.
I think you need to describe the problem clearly otherwise when the maintainer looks at the issue, he will not understand what you are trying to solve.
Are we saying that the other plugins work differently depending on you entering the number vs copying vs using autoconplete? In that case, it looks like x-mask does a better job at staying consistent. It also sounds like it would be a lot of work to make it work the way you like.
If it's causing pains in your application, you can maybe disable the autocomplete?
There was a problem hiding this comment.
To confirm provided a user input of Perhaps its the special nature of the phone number input but we definitely see a large number of users that have the more 'raw' format stored in autocomplete (and we would like to leverage if we can and do with other masking tools)
|
|
Closing in favor of: #4260 |
Closes #4252
Found where a non wildcard value matched the user input the value was being stripped, I added an additional check before stripping and added a couple test cases to the jest tests.