Password value binding triggers updateTarget?
I am observing a strange beahvior that is causing me trouble.
I have a simple value binding + behavior on a password field:
<input type=password value.bind="p & validate" />.
When I type text in the input, I see updateSource is called, as expect.
When I mash keys -- or simply press two keys at the same time -- it seems updateTarget is called as well. But why? This is causing unwanted side-effects in my binding behavior.
This is easy to reproduce in IE11 with a password box: just hit two keys at the same time. It seems it sometimes happens with a normal textbox as well, but it is a lot harder to reproduce.
does it happen in other browsers too? Whats the call stack? Can you provide a plunker?
It does easily happen in Edge as well. Does not seem to happen on Firefox. Untested in Chrome.
Here's a plunker: https://plnkr.co/9cF0XO8FjPK6relatTf5
There's one updateTarget at startup, which is probably because I did not define x on the model, so it gets updated from undefined to "" (I guess).
But then if you hit two keys at the same time, you very easily get a updateTarget on IE11 and Edge.
As for the callstack, I would like to take the opportunity to say that the TaskQueue makes it often quite hard to track causality. All the bindings are updated in this micro-queue... I wonder if there is a way to opt-in long stack traces like built-in async callbacks do in the Edge debugger callstack.
I see it happening in edge too. not in chrome, firefox or IE11.
https://plnkr.co/edit/ahRwzTeRjFeCYKUs0U1c?p=preview
@jdanyow Good that you can reproduce it! I experienced it first on IE11, not sure why you don't.
Any idea where it comes from?
No, not yet. I also looked at adding a "long stack traces" plugin for the TaskQueue to help with the debugging thing you mentioned.
Did you ever find a fix for this? I'm experiencing the same problem; I've narrowed it down to Binding.prototype.call in Aurelia-binding.js. what I'm seeing is that in Chrome when pressing two keys at once in a textarea input that when getting the value from the textarea it only includes the first key typed, but in IE11 it shows both keys - hence it executes the code if (newValue !== oldValue). I hope that makes sense. I came across this from users telling me the cursor always jumped to the end of their text if they moved back into the text and typed quickly.
@jdanyow Putting this back on your radar.
Stale since 2016
@jdanyow Can you comment?
or @jods4 ? (-:
@Alexander-Taran Unfortunately the plunker is gone but I think the description of the problem is clear?