Vuetify: 1.0.19
Vue: 2.5.16
Browsers: Chrome 67.0.3396.99
OS: Linux x86_64
The mask should show: 255/55 R18 92H.
The mask shows: 255/55 R89 2
https://codepen.io/clausstraube/pen/PaxOxN
If I change the mask to 'mask="###/## -## ##A"' (- for R) everything works as expected.
We have to do a re-evaluation of our current masking features.
it can be reproduct, if you would type very faster. For example i have mask +# ### ### ## ## and if i type all of numerals very fast, i can reproduct this bug.
Having this same issue at the moment and it's infuriating. I have a computed mask for phone numbers that detect regional phone formats, as soon as the mask changes, the cursor relocates to after the first character.
phoneMask.js
const mobile = '#### ### ###'
const landline = '## #### ####'
const intl = '(+##) ### ### ###'
export default function phone(v) {
if (!(v && v.length >= 2)) return null;
let start = v.substring(0, 2)
if (start === '04') return mobile;
if (start === '07') return landline;
return intl;
}
phoneInput.vue
import phoneMask from "@/lib/phoneMask";
export default {
name: "PhoneNumber",
props: {
value: String
},
computed: {
mask() {
return phoneMask(this.value)
}
}
};
This was a feature that lost it's champion. Apparently masks aren't not something most people like and it's just low on triage for us.
This appears to be something going wrong in mixins\maskable.js.
I have a feeling it has something to do with determining the cursor position at the end of the string and ignoring whitespace (in both my example and the one from OP, there is whitespace next to the cursor position). I think when it is determining the next cursor location, it doesn't include the white-space, and drops the cursor in the wrong location (or something similar).
I'll debug further to see if there's a simple answer, but there are so many cases to be considered that it's hard to come up with a simple fix.
Removed that PR yesterday because my SCM absolutely destroyed the working tree on my branch when I tried to rebase to master.
@johnleider insists on adding a unit test for maskable (which for some reason was never written) before merging the PR which is a single-line fix, the issue in this thread would probably only be able to be tested using E2E, so there's a good few hours of test writing and work involved in merging a 1-line PR, so I'm going to shelve this for now as I don't have the time this week to work on it.
For those interested, calling resetSelections() inside of the mask function in mixins\maskable.js seems to be the solution. Maskable keeps track of the caret location and if the mask changes, doesn't behave as it should.
masks have been removed in 2.0