-
Notifications
You must be signed in to change notification settings - Fork 422
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unescaped attributes #664
Unescaped attributes #664
Conversation
// If not, add `doubleParent` to close push and text. | ||
"}));\n" | ||
); | ||
buff.push(insert_cmd, "can.view.txt(\n" + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sykopomp can you identify the change in this section?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All attributes are escaped here. status() is a string when the value is inside an attribute.
This takes care of a bug where attribute values would sometimes have html entities in them when the content was escaped. For example, & in an attribute value string would show up as & in the actual attribute value. The only case where we actually want to escape attributes in can.view is when they're immediately concatenated because they're simple strings.
The current code passes the modified tests in the pull request without any changes. The escaping really only applies to HTML tag escaping (it doesn't do ampersands). I'd disagree that attributes should always be ampersand escaped, I'd expect that your original content should be "x&y" in that case. |
Conflicts: view/mustache/mustache_test.js
This is ready to merge pending some external changes involving test running. |
This fixes an issue where, say:
would render things such that
element.title === "x&y"
This makes it so that
{{{x}}}
and{{x}}
, when applied to attributes, always do the exact same thing. It does not make sense for us to allow unescaped attribute values incan.view
EDIT: I found out after looking closer that this was only affecting things inside
{{#foo}}
blocks. This does fix that issue, and things continue to work as before. I've added a new test that specifically checks escaping inside blocks within attributes.