Opened 15 years ago

Closed 15 years ago

Last modified 12 years ago

#10675 closed (fixed)

escapejs doesn't handle U+2028 LINE SEPARATOR

Reported by: Ole Laursen Owned by: Rich Leland
Component: Template system Version: 1.0
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I'm doing something like this:

<script>
var myvar = "{{ somestring|escapesj|safe }}";
</script>

Now one of my users somehow managed to put in a U+2028 character in somestring (darn Mac freak) which upon investigation turns out be "LINE SEPARATOR - may be used to represent this semantic unambiguously". This makes Firefox barf with a SyntaxError: unterminated string literal which breaks the script. So it seems escapejs should handle this character, too.

Attachments (2)

linefeed (6 bytes ) - added by Ole Laursen 15 years ago.
Text file with the character embedded (encoded in UTF-8), might be helpful
10675.diff (1007 bytes ) - added by Rich Leland 15 years ago.

Download all attachments as: .zip

Change History (12)

by Ole Laursen, 15 years ago

Attachment: linefeed added

Text file with the character embedded (encoded in UTF-8), might be helpful

comment:1 by Jacob, 15 years ago

milestone: 1.1
Triage Stage: UnreviewedAccepted

comment:2 by anonymous, 15 years ago

Owner: changed from nobody to anonymous
Status: newassigned

comment:3 by Rich Leland, 15 years ago

Owner: changed from anonymous to Rich Leland
Status: assignednew

comment:4 by Rich Leland, 15 years ago

used attachment "linefeed" and was able to re-create. beginning work on fix.

by Rich Leland, 15 years ago

Attachment: 10675.diff added

comment:5 by Rich Leland, 15 years ago

Has patch: set

After some research, JavaScript barfs on paragraph separator U+2029 as well. Patch supplies fix for both.

comment:6 by Malcolm Tredinnick, 15 years ago

Since we're not replacing any other linebreak characters (e.g. \r and \n) with the empty string, why do you think that is that the correct thing to do here? I'm primarily wondering why we aren't replacing it with the Javascript hex representations for those characters (\x2028, etc). The escapejs filter doesn't change the content at all. It just makes it representable in Javascript and this patch is changing that.

Looks like those are the only two special linebreak characters we need to worry about here.

comment:7 by Malcolm Tredinnick, 15 years ago

Resolution: fixed
Status: newclosed

Fixed in r10543. I didn't take the exact path here, since that threw away information. Instead, we now escape those problematic characters.

comment:8 by Malcolm Tredinnick, 15 years ago

(In [10544]) [1.0.X] Fixed #10675 -- Added unicode paragraph and line-sep handling to escapejs.

There were a couple of line breaking Unicode characters (\u2028 and
\u2029) that cause Javascript errors, at least in Firefox, if not
escaped. So now we do so. Based on a patch from rleland.

Backport of r10543 from trunk.

comment:9 by Ole Laursen, 15 years ago

Thanks to both of you!

comment:10 by Jacob, 12 years ago

milestone: 1.1

Milestone 1.1 deleted

Note: See TracTickets for help on using tickets.
Back to Top