This repository has been archived by the owner on Apr 12, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 27.5k
Infinite $digest Loop when using $sce with filter #3980
Milestone
Comments
Workaround also applicable here: #3932 (comment) |
rodyhaddad
added a commit
to rodyhaddad/angular.js
that referenced
this issue
Sep 18, 2013
ghost
assigned chirayuk
Sep 20, 2013
chirayuk
added a commit
to chirayuk/angular.js
that referenced
this issue
Sep 20, 2013
Ref: angular#4045 I have this sinking feeling that support this use case sort of encourages binding to function that blindly trust some html. For now, I'm fixing the issue while I think about the use cases some more. In the case of a function that performs any non-trivial work before wrapping the value (e.g. the showdown filter in issue angular#3980, or the binding to a simply wrapper function in issue angular#3932 if it did anything meaty), this fix makes it "work" - but performance is going to suck - you should bind to some other thing on scope that watches the actual source and adjusts itself when that changes (e.g. the showdown filter.) For the case of the wrapper in angular#3932, if one isn't performing sanitization or some such thing - then you the developer has insight into why that value is safe in that particular context - and it should be available simply by name and not as a result of a function taking any arbitrary input to make auditing of security a little saner. Closes angular#3932, angular#3980
Fixed in e2068ad |
jamesdaily
pushed a commit
to jamesdaily/angular.js
that referenced
this issue
Sep 25, 2013
Ref: angular#4045 I have this sinking feeling that support this use case sort of encourages binding to function that blindly trust some html. For now, I'm fixing the issue while I think about the use cases some more. In the case of a function that performs any non-trivial work before wrapping the value (e.g. the showdown filter in issue angular#3980, or the binding to a simply wrapper function in issue angular#3932 if it did anything meaty), this fix makes it "work" - but performance is going to suck - you should bind to some other thing on scope that watches the actual source and adjusts itself when that changes (e.g. the showdown filter.) For the case of the wrapper in angular#3932, if one isn't performing sanitization or some such thing - then you the developer has insight into why that value is safe in that particular context - and it should be available simply by name and not as a result of a function taking any arbitrary input to make auditing of security a little saner. Closes angular#3932, angular#3980
jamesdaily
pushed a commit
to jamesdaily/angular.js
that referenced
this issue
Jan 27, 2014
Ref: angular#4045 I have this sinking feeling that support this use case sort of encourages binding to function that blindly trust some html. For now, I'm fixing the issue while I think about the use cases some more. In the case of a function that performs any non-trivial work before wrapping the value (e.g. the showdown filter in issue angular#3980, or the binding to a simply wrapper function in issue angular#3932 if it did anything meaty), this fix makes it "work" - but performance is going to suck - you should bind to some other thing on scope that watches the actual source and adjusts itself when that changes (e.g. the showdown filter.) For the case of the wrapper in angular#3932, if one isn't performing sanitization or some such thing - then you the developer has insight into why that value is safe in that particular context - and it should be available simply by name and not as a result of a function taking any arbitrary input to make auditing of security a little saner. Closes angular#3932, angular#3980
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This example http://jsfiddle.net/FmeP9/ produce Error: [$rootScope:infdig] using this code:
It is working but i think perfomnce will go down if those error shows up.
The text was updated successfully, but these errors were encountered: