Bug with asynchronous text field updates #1827
Comments
When binding the result of a promise directly to an ng:model directive, getterFn successfully extracts the data from the promise by traversing the '$$v' attribute. However the setterFn was not successfully traversing to the $$v attribute, and instead writing model updates directly on the promise itself. The subsequent apply/digest phase of Angular was then pulling the original value from the promise and applying it back into the viewState, thus simulating a read-only field. In summary, setterFn was writing to the root of the promise, while getterFn was reading from the '$$v' component. Fixed by modifying setterFn to unwrap promises if found and read $$v. If promises have not been resolved yet, bindings will function as they previously did (act as a read-only field). This appears to be more of a side effect than intentional design in the existing codebase, however I kept this behaviour in this patch to minimize the chance of breaking existing projects. Closes angular#1827 Also see: http://stackoverflow.com/questions/16883239/angularjs-ngmodel- field-is-readonly-when-bound-to-q-promise/16883387
|
is it possible to somehow patch the current version of angular with this fix (by overwriuting methods or so). We are experiencing this bug in production :-(. So i am looking for a fast solution. |
|
Unfortunately the method in question is in a closed namespace, so can't be monkey patched. However you can checkout my patch from github and build a minified version of angular with the patch yourself. |
|
I though I was doing something wrong or that binding to promises wasn't fully supported. Thanks, I patched it and all works now. |
|
Manually patching this has worked from my side can we please include this fix. |
|
I really think that would be much better off if AngularJS did no auto-unwrapping of promises at all! This syntactic sugar really only creates confusion. For instance, while directly interpolating a promise gets unwrapped: A interpolating a function that returns a promise doesn't: |
|
There's probably still other edge cases where it doesn't work - my patch attempts to fix one. For consistency I think it makes sense to go all-in or nothing. The problem is the number of applications that are currently using this feature - removing it would break a large number of in-production sites. Perhaps a compromise - allowing a helper to be mixed into the current scope to enable this feature explicitly only when desired? It's an extremely useful and powerful feature when used properly, and my codebase is substantially simpler for having it. |
I think I found a bug in Angular 1.0.3 (and beyond.)
Check this jsFiddle:
http://jsfiddle.net/sonicsage/k8W4Y/6/
Notice that after the text field updates, it is uneditable.
If you switch to Angular 1.0.2, it is editable.
On the Google Group, Peter Bacon Darwin responded:
"I think this may be a bug in the $parser that parses the original user.name on a Promise object. Can you submit an issue to GitHub? It seems that the ngModelGet function, which is created by the $parse service inside the ngModelController is not returning the correct value. Pete"
The text was updated successfully, but these errors were encountered: