Open michalsukupcak opened 8 years ago
Argh, yeah, this looks like a bug: http://jsbin.com/gaceku/edit?html,output
If we do what you say, and skip _onValueChanged
if the element isn't focused, then won't something like `someInput.value = '12345678' stop working?
Unfortunately yes, you are correct - that will allow setting a value, but validation won't be triggered.
I did my own paper-input implementation (heavily inspired by gold-phone-input) with the same caret position resetting issue (as I only modified the code to specific formatting requirements), and this is a fix that is working for me for the validation problem when value is set imperatively:
_onValueChanged: function (value, oldValue) {
if (value !== oldValue && value !== '' && value !== null && value !== undefined) {
value = value ? value.toString() : '';
var start = this.$.input.selectionStart;
// Input formatting similar to gold-phone-input is here,
// removed to shorten the sample as it is irrelevant ...
// Update caret position only when input is focused
if (this.focused) {
var updatedSpacesBeforeCaret = formattedValue.substr(0, start).split(' ').length - 1;
var spacesDifference = updatedSpacesBeforeCaret - initialSpacesBeforeCaret;
this.updateValueAndPreserveCaret(formattedValue.trim());
this.$.input.selectionStart = this.$.input.selectionEnd = start + spacesDifference;
} else { // Otherwise (input not focused), simply just update the internal value
this.value = formattedValue.trim();
}
this._handleAutoValidate();
}
},
I removed the focus condition from the beginning of the function and only wrapped the piece of code handling caret position and added simple this.value update when input isn't focused. Result:
Can't say if it is the best or correct solution (is it ok to set this.value inside _onValueChanged?), but at least it seems to work. :)
Description
When the same variable is bound to multiple element instances, eg.:
Then usage of PaperInputBehavior.updateValueAndPreserveCaret inside _onValueChanged observer causes after any user input the caret to bug and reset its position always back to beginning (start) of the input, so user effectively types in RTL direction.
IMHO the issue is caused by the fact that change in value of one input triggers change in the other input, which triggers change back. The subsequent changes detect no caret positions (this.$.input.selectionStart equals to 0) and therefore the position resets back to the beginning of the input.
Quick workaround that prevents the issue from happening is adding a check at the beginning of the _onValueChanged observer for input focus (this.focused === true), therefore preventing the observer code from being executed unless user actually has focus on the input and is typing in the specific element instance.
Issue occurs in Chrome (50) on Linux (Ubuntu 16.04), doesn't occur under Firefox (46) on the same OS.
Expected outcome
Caret position follows user input naturally.
Actual outcome
Caret gets reset to initial position (start of the input).
Steps to reproduce