Django

Code

Ticket #10675 (closed: fixed)

Opened 1 year ago

Last modified 1 year ago

escapejs doesn't handle U+2028 LINE SEPARATOR

Reported by: olau Assigned to: rleland
Milestone: 1.1 Component: Template system
Version: 1.0 Keywords:
Cc: Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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

linefeed (6 bytes) - added by olau on 03/31/09 06:03:06.
Text file with the character embedded (encoded in UTF-8), might be helpful
10675.diff (1.0 kB) - added by rleland on 04/09/09 22:27:00.

Change History

03/31/09 06:03:06 changed by olau

  • attachment linefeed added.

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

04/02/09 10:02:34 changed by jacob

  • needs_better_patch changed.
  • needs_docs changed.
  • stage changed from Unreviewed to Accepted.
  • needs_tests changed.
  • milestone set to 1.1.

04/08/09 07:41:18 changed by anonymous

  • owner changed from nobody to anonymous.
  • status changed from new to assigned.

04/08/09 07:41:50 changed by rleland

  • owner changed from anonymous to rleland.
  • status changed from assigned to new.

04/08/09 07:43:14 changed by rleland

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

04/09/09 22:27:00 changed by rleland

  • attachment 10675.diff added.

04/09/09 22:35:01 changed by rleland

  • has_patch set to 1.

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

04/11/09 01:45:13 changed 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.

04/11/09 23:56:30 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

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

04/11/09 23:57:51 changed 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.

04/14/09 04:16:57 changed by olau

Thanks to both of you!

Add/Change #10675 (escapejs doesn't handle U+2028 LINE SEPARATOR)




Change Properties
Action