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
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
Put 2 gold-email-input elements into the page.
Bind the same variable to both inputs.
Start typing into one of the elements.
The text was updated successfully, but these errors were encountered:
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:
caret position continues to work correctly (doesn't reset on user input),
input validation works even if the value is set imperatively in code (input is marked as invalid).
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
The text was updated successfully, but these errors were encountered: