escapejs doesn't handle U+2028 LINE SEPARATOR

[Ole Laursen]

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.

[Ole Laursen]

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

[Rich Leland]

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

[Rich Leland]

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

[Malcolm Tredinnick]

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.

[Malcolm Tredinnick]

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

[Malcolm Tredinnick]

(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.

[Ole Laursen]

Thanks to both of you!

[Jacob]

Milestone 1.1 deleted