Opened 6 years ago

Closed 6 years ago

Last modified 4 years ago

#10675 closed (fixed)

escapejs doesn't handle U+2028 LINE SEPARATOR

Reported by: olau Owned by: rleland
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: UI/UX:

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 olau 6 years ago.
Text file with the character embedded (encoded in UTF-8), might be helpful
10675.diff (1007 bytes) - added by rleland 6 years ago.

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by olau

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

comment:1 Changed 6 years ago by jacob

  • milestone set to 1.1
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

comment:2 Changed 6 years ago by anonymous

  • Owner changed from nobody to anonymous
  • Status changed from new to assigned

comment:3 Changed 6 years ago by rleland

  • Owner changed from anonymous to rleland
  • Status changed from assigned to new

comment:4 Changed 6 years ago by rleland

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

Changed 6 years ago by rleland

comment:5 Changed 6 years ago by rleland

  • Has patch set

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

comment:6 Changed 6 years ago by mtredinnick

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 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from new to closed

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 Changed 6 years ago by mtredinnick

(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 Changed 6 years ago by olau

Thanks to both of you!

comment:10 Changed 4 years ago by jacob

  • milestone 1.1 deleted

Milestone 1.1 deleted

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