Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

Infinite $digest Loop when using $sce with filter #3980

Closed
johaa1993 opened this issue Sep 12, 2013 · 3 comments
Closed

Infinite $digest Loop when using $sce with filter #3980

johaa1993 opened this issue Sep 12, 2013 · 3 comments
Assignees
Milestone

Comments

@johaa1993
Copy link

This example http://jsfiddle.net/FmeP9/ produce Error: [$rootScope:infdig] using this code:

filter('markdown', function ($sce) {
    var converter = new Showdown.converter();
    return function (value) {
        var html = converter.makeHtml(value || '');
        return $sce.trustAsHtml(html);
    };
});

It is working but i think perfomnce will go down if those error shows up.

@ahoereth
Copy link

Workaround also applicable here: #3932 (comment)

@chirayuk
Copy link
Contributor

#4045 (comment)

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
@chirayuk
Copy link
Contributor

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.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants