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
However, it seems there is still a bug existing when you try to edit the input from the middle.
For example with this phone number "123-456-7890",
if you edit the number "123" or "456", then the cursor jumps to the back.
This is happening both on web and mobile.
The jumping back issue on number fields with v.1.14.15 seems to be fixed on desktop only, but from my android device with Chrome and Samsung Internet browser, if you type the phone number (123) 456-7890, it becomes (234) 789-0651. I'm not sure if this is happening on Apple devices as well. There was no this issue with v.1.14.14 if you add "autocomplete=off" on the input fields.
Sorry, there was a typo in my previous comment with the version number. I edited it. So, There was no this issue with v.1.14.14 if you add "autocomplete=off" on the input fields. With new version v.1.14.15, it is broken even if you added "autocomplete=off".
I don't fully understand your code, but in my opinion, I can come up 2 possibilities.
"el.attr('autocomplete', 'off');" could apply after you submit.
How about pointing manually instead of "el", so .. for example,
input[type=text] or input[type=number]
@didauds the problem with v.1.14.14 is that it breaks a lot more than it fixes. I don't understand why these android browsers need to be such a pain in the ass! xD
I was able to reproduce the same steps as @knyazevdev told.
And it`s not only over Chrome, but even over IE and Firefox.
@igorescobar, se você precisar de ajudar para debugar isso eu me coloco à disposiçao, mas estou tendo exatamente o mesmo tipo de problema que reportado pelos outros dois usuários, e nao está sendo nem em uma implementaçao que fiz, mas direto em seu site. Os passos dados pelo usuário sao precisos e suficientes para reproduzir. O problema está em números que tem o "." se voce tentar com 1.234,56 vai conseguir reproduzir.
@victorsantoss@didauds I just realized that this only happens when the mask shrinks. 000,00 works, 0.000,00 doesn't because when you type the first digit the pattern becomes 000,00 and rapidly turns 0.000,00 again. 00.000,00 also works because when you erase the first digit it remains with the same structure. It gives some leads on why this is happening.
The easiest way to replicate this is to type really fast in the input.
It happens every time. it seems like it has to do when the mask detects if a format character (like a ')' should be placed after input.
replicate:
1.) $('.phone').mask('(000) 000-0000');
2.) In the phone input type numbers really fast.
I located this during automated UAT testing with selenium. The input seems to jumble up only when I use this input method. (Nightwatch + Selenium + WebDriver)
expected "(314) 555-5252" but got: "(143) 555-2525"
We've also run into this problem but it only reproducible through Selenium at the moment. I've tried some tests written in CypressJS but they work without a problem. I have a theory that it may also depend on the power of the machine running the browser causing a sort of race condition but I have no strong evidence of this yet.
I used victorsantoss' comment to go from SendKeys("some text") to sending a key at a time with a 10 ms sleep between keys and entering issues where solved.
Activity
[-]Cursor jumps to the back when edit the input[/-][+]Cursor jumps to the back when edit the mask input[/+]igorescobar commentedon Mar 8, 2018
@didauds Thanks for reporting! Can you check again?
didauds commentedon Mar 9, 2018
Thank you igorescobar for your quick response.
However..
$("input#postal").mask("S0S 0S0", {
'translation': {
S: {pattern: /[A-Za-z]/},
0: {pattern: /[0-9]/}
}
,onKeyPress: function (value, event) {
event.currentTarget.value = value.toUpperCase();
}
});
Thank you
igorescobar commentedon Mar 9, 2018
@didauds can you verifiy why this:
https://github.com/igorescobar/jQuery-Mask-Plugin/blob/master/src/jquery.mask.js#L444
Isn't working for you?
didauds commentedon Mar 9, 2018
Sorry, there was a typo in my previous comment with the version number. I edited it. So, There was no this issue with v.1.14.14 if you add "autocomplete=off" on the input fields. With new version v.1.14.15, it is broken even if you added "autocomplete=off".
I don't fully understand your code, but in my opinion, I can come up 2 possibilities.
"el.attr('autocomplete', 'off');" could apply after you submit.
How about pointing manually instead of "el", so .. for example,
input[type=text] or input[type=number]
igorescobar commentedon Mar 9, 2018
@didauds the problem with v.1.14.14 is that it breaks a lot more than it fixes. I don't understand why these android browsers need to be such a pain in the ass! xD
didauds commentedon Mar 9, 2018
@igorescobar yeh, it may be similar to dealing with IE when you develop some web stuff whereas Chrome worked fine. :)
Anyways, I may need to use v.1.14.14 for now until this issue is fixed because v.1.14.15 has more issues from my side and requirements.
Feel free to let me know if you need a guinea pig for this fix.
knyazevdev commentedon Mar 12, 2018
Hi, @igorescobar
Chrome browser.
The digits are displayed in reverse order.
Thank you!
didauds commentedon Mar 14, 2018
Hi, @igorescobar,
Is there any update?
Thank you,
igorescobar commentedon Mar 14, 2018
@didauds I need your help guys. I can't fix a problem that I can't reproduce on any devices I have.
didauds commentedon Mar 14, 2018
Sure, let's try step by step.
Can you have a look first ..
Try edit inputs on "Mixed Type Mask" on your webpage "https://igorescobar.github.io/jQuery-Mask-Plugin/"
The issue mentioned by @knyazevdev above.
These may not be related with Android device stuff.
igorescobar commentedon Mar 14, 2018
I also couldn't reproduce the issue @knyazevdev is saying... 😞
victorsantoss commentedon Mar 26, 2018
I was able to reproduce the same steps as @knyazevdev told.
And it`s not only over Chrome, but even over IE and Firefox.
@igorescobar, se você precisar de ajudar para debugar isso eu me coloco à disposiçao, mas estou tendo exatamente o mesmo tipo de problema que reportado pelos outros dois usuários, e nao está sendo nem em uma implementaçao que fiz, mas direto em seu site. Os passos dados pelo usuário sao precisos e suficientes para reproduzir. O problema está em números que tem o "." se voce tentar com 1.234,56 vai conseguir reproduzir.
igorescobar commentedon Apr 18, 2018
@victorsantoss @didauds I just realized that this only happens when the mask shrinks.
000,00
works,0.000,00
doesn't because when you type the first digit the pattern becomes000,00
and rapidly turns0.000,00
again.00.000,00
also works because when you erase the first digit it remains with the same structure. It gives some leads on why this is happening.victorsantoss commentedon Apr 19, 2018
@igorescobar with that in mind I probably can help you out. I’ll start regarding the code to see if I’m able to do that.
brycefranzen commentedon May 1, 2018
Still a problem in the latest release. When masking US phone number, upon first character typing cursor jumps back to the beginning.
ryanm352 commentedon Sep 21, 2018
The easiest way to replicate this is to type really fast in the input.
It happens every time. it seems like it has to do when the mask detects if a format character (like a ')' should be placed after input.
replicate:
1.) $('.phone').mask('(000) 000-0000');
2.) In the phone input type numbers really fast.
This does not happen with cut and paste, btw.
SourceCode commentedon Nov 6, 2018
I located this during automated UAT testing with selenium. The input seems to jumble up only when I use this input method. (Nightwatch + Selenium + WebDriver)
expected "(314) 555-5252" but got: "(143) 555-2525"
jpierson commentedon Feb 28, 2019
We've also run into this problem but it only reproducible through Selenium at the moment. I've tried some tests written in CypressJS but they work without a problem. I have a theory that it may also depend on the power of the machine running the browser causing a sort of race condition but I have no strong evidence of this yet.
victorsantoss commentedon Mar 4, 2019
The problem isn't linked with the fact of using webdrivers to fill the input, but with the "speed" that you're capable to type.
If you try to type very fast, you'll be able to see that the cursor will be scared and will jump to the wrong place =p
BasHamer commentedon May 2, 2019
I used victorsantoss' comment to go from SendKeys("some text") to sending a key at a time with a 10 ms sleep between keys and entering issues where solved.