Skip to content
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

Merged
merged 5 commits into from
Jan 23, 2014
Merged

Unescaped attributes #664

merged 5 commits into from
Jan 23, 2014

Conversation

zkat
Copy link
Contributor

@zkat zkat commented Jan 14, 2014

This fixes an issue where, say:

can.view.mustache("<foo title='{{hi}}'")({hi: "x&y"})

would render things such that element.title === "x&amp;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 in can.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.

// If not, add `doubleParent` to close push and text.
"}));\n"
);
buff.push(insert_cmd, "can.view.txt(\n" +
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Josh Marchán added 2 commits January 16, 2014 18:29
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 &amp; 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.
@andykant
Copy link
Contributor

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.

Josh Marchán and others added 2 commits January 21, 2014 21:20
@andykant
Copy link
Contributor

This is ready to merge pending some external changes involving test running.

@ghost ghost assigned andykant Jan 23, 2014
andykant added a commit that referenced this pull request Jan 23, 2014
@andykant andykant merged commit 12cbd6f into master Jan 23, 2014
@andykant andykant deleted the unescaped-attributes branch January 23, 2014 19:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants