Fix bug in X-Mask where user input that matched the non wildcard value were being stripped

[robertmarney]

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.

[ekwoka]

This can never evaluate to true.

It's saying "if these match and if they also don't match" which is impossible.

[robertmarney]

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.

[ekwoka]

Ah yes, you're right. That's hard to read.

[ekwoka]

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.

[ekwoka]

Suggested change

	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

[robertmarney]

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)

[SimoTod]

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.

[robertmarney]

@SimoTod - The bug is the application of autocomplete values

[SimoTod]

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?

[robertmarney]

Hey @SimoTod - Your feedback is fair, apologies for the lack of clarity.

If I can get a working solution would you accept a PR?

As @ekwoka mentioned, as tests are passed, we might want to align on the spec (preference for Jest) of what we expect the mask to do for some of these more complex cases?

[robertmarney]

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.

To confirm provided a user input of 3133133113' the expectation is the output is +1(333)133-113?

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)

[robertmarney]

Closing in favor of: #4260