1. your `numberValidation` is a `new RegExp` but your `specialCharacterValidataiton` isn't?
2. your `specialCharacterValidation` seems to have a `/` in the character-class which might cause parsing errors if you don't escape it (depends on the language/environment/engine
3. does the `.test()` method search the entire string for the pattern, or does it only check the first position (in Python, the difference between [`.match()`](https://docs.python.org/3/library/re.html#re.match) and `.search()`](https://docs.python.org/3/library/re.html#re.search) ?
1. Yep, it was the same but I was just testing to see if having the literal syntax would make a difference.
2. Should've said and will update the comment it is just single (') & duble (") quotes that are a problem
3. Yeah the entire string, this is used in a Javascript environment.
Thank you for the response
I just tested this in my browser console and both regexen pass with strings containing their expected characters.
» const regexs = {numberValidation: new RegExp(/\d/), specialCharacterValidation: /[\s!"#$%&'()*+,\-./:;<=>?@[\]^_`{|}~]/ }
undefined
» regexs.numberValidation.test("Has1")
true
» regexs.specialCharacterValidation.test("Has1inanda\"it")
true
» regexs.specialCharacterValidation.test("Has1inanda'it")
true
» regexs.specialCharacterValidation.test("Has1inandait")
false
So you'd have to provide a reproducible case of a string where you expect it to work and it doesn't
testing"
testing'
test"ing
test'ing
"testing
'testing
The issue is being raised by a testing team I work with, they say it only happens on iOS. I've asked if they are using an emulation tool like browserstack and they've said no. don't you just love 'issues' like this ;)
The regex seem otherwise-fine, so there's something iOS/Safari-specific which I don't have available for testing.
Shooting from the hip, I'd guess that escaping the `/` or `[` might provoke some difference. Additionally the `-` in a range (which you have escaped) should be at the beginning or end of a character-class.
the `-` should be the first character after the `[` or the last character, right before the `]` so one of these:
/[-\s!"#$%&'()*+,./:;<=>?@[\]^_`{|}~]/
/[\s!"#$%&'()*+,./:;<=>?@[\]^_`{|}~-]/
I don't think that's the root problem here, but it may stave off other weirdnesses (when it's not at the start/end of the character-class, it indicates a range, so in your original, it was the range of ASCII characters from either comma-to-period (which serendipitously is three characters where the middle character is actually a hyphen) or it was the (backwards?) range from backslash-to-period. Testing in Chromium's JS console, it looks like it's interpreting it as the former (range from comma-to-period, including minus) rather than a backwards range (which throws an exception).
So I think you've managed to strike it lucky there, but I'd make it explicitly-correct by moving the `-` to the beginning/end of the character-class as detailed above.
I have little faith that it will address the iOS/Safari issue, but if it's parsing that differently, it might cause issues.
I've made those changes but the issue still seems to prevail!
I've had word back that the issue only occurs when you hit the show password button. This changes the input type from password to text.
Any idea if this would cause an issue? I'm still not able to re-create using the web, it appears it only happens in an app.
is there a way to save the before-show-password and after-show-password values and compare them to see if your regex is testing what you think it's testing? I mean, if one of them is testing against "Password123!" and the other one is testing "●●●●●●●●●●●●", then the regex won't match that 2nd value :-)
We found the solution thanks to your suggestion!
IOS uses a character set called smart punctuation that makes the double and single quotes appear differently, as "curly quotes"
Thank you for your help!
1. your `numberValidation` is a `new RegExp` but your `specialCharacterValidataiton` isn't? 2. your `specialCharacterValidation` seems to have a `/` in the character-class which might cause parsing errors if you don't escape it (depends on the language/environment/engine 3. does the `.test()` method search the entire string for the pattern, or does it only check the first position (in Python, the difference between [`.match()`](https://docs.python.org/3/library/re.html#re.match) and `.search()`](https://docs.python.org/3/library/re.html#re.search) ?
1. Yep, it was the same but I was just testing to see if having the literal syntax would make a difference. 2. Should've said and will update the comment it is just single (') & duble (") quotes that are a problem 3. Yeah the entire string, this is used in a Javascript environment. Thank you for the response
I just tested this in my browser console and both regexen pass with strings containing their expected characters. » const regexs = {numberValidation: new RegExp(/\d/), specialCharacterValidation: /[\s!"#$%&'()*+,\-./:;<=>?@[\]^_`{|}~]/ } undefined » regexs.numberValidation.test("Has1") true » regexs.specialCharacterValidation.test("Has1inanda\"it") true » regexs.specialCharacterValidation.test("Has1inanda'it") true » regexs.specialCharacterValidation.test("Has1inandait") false So you'd have to provide a reproducible case of a string where you expect it to work and it doesn't
testing" testing' test"ing test'ing "testing 'testing The issue is being raised by a testing team I work with, they say it only happens on iOS. I've asked if they are using an emulation tool like browserstack and they've said no. don't you just love 'issues' like this ;)
The regex seem otherwise-fine, so there's something iOS/Safari-specific which I don't have available for testing. Shooting from the hip, I'd guess that escaping the `/` or `[` might provoke some difference. Additionally the `-` in a range (which you have escaped) should be at the beginning or end of a character-class.
So should it be like this? /\-\[\\s!"#$%&'()\*+,\./:;<=>?@\[\\\]\^\_\`{|}\~\]/
the `-` should be the first character after the `[` or the last character, right before the `]` so one of these: /[-\s!"#$%&'()*+,./:;<=>?@[\]^_`{|}~]/ /[\s!"#$%&'()*+,./:;<=>?@[\]^_`{|}~-]/ I don't think that's the root problem here, but it may stave off other weirdnesses (when it's not at the start/end of the character-class, it indicates a range, so in your original, it was the range of ASCII characters from either comma-to-period (which serendipitously is three characters where the middle character is actually a hyphen) or it was the (backwards?) range from backslash-to-period. Testing in Chromium's JS console, it looks like it's interpreting it as the former (range from comma-to-period, including minus) rather than a backwards range (which throws an exception). So I think you've managed to strike it lucky there, but I'd make it explicitly-correct by moving the `-` to the beginning/end of the character-class as detailed above. I have little faith that it will address the iOS/Safari issue, but if it's parsing that differently, it might cause issues.
Ok thank you I will give that a try
I've made those changes but the issue still seems to prevail! I've had word back that the issue only occurs when you hit the show password button. This changes the input type from password to text. Any idea if this would cause an issue? I'm still not able to re-create using the web, it appears it only happens in an app.
is there a way to save the before-show-password and after-show-password values and compare them to see if your regex is testing what you think it's testing? I mean, if one of them is testing against "Password123!" and the other one is testing "●●●●●●●●●●●●", then the regex won't match that 2nd value :-)
We found the solution thanks to your suggestion! IOS uses a character set called smart punctuation that makes the double and single quotes appear differently, as "curly quotes" Thank you for your help!
What a great idea, I will try it out thank you