ensure u2029 is escaped in escape_javascript helper #5380

merged 1 commit into from Mar 12, 2012


None yet
4 participants

benmmurphy commented Mar 11, 2012

similar to issue #2587

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf (section 7.3)

The ECMAScript line terminator characters are listed in Table 3.
Table 3 — Line Terminator Characters
Code Unit Value Name Formal Name
\u000A Line Feed <LF>
\u000D Carriage Return  <CR>
\u2028 Line separator <LS>
\u2029 Paragraph separator <PS>

@tenderlove tenderlove added a commit that referenced this pull request Mar 12, 2012

@tenderlove tenderlove Merge pull request #5380 from benmmurphy/escape_unicode_paragraph_sep…

ensure u2029 is escaped in escape_javascript helper

@tenderlove tenderlove merged commit dea486d into rails:master Mar 12, 2012

My Rails 3.2.2 application was working fine, but after upgrading to 3.2.3, some of my ajax requests stopped working. I finally tracked it down to this specific change. In my ajax response, I'm rendering a partial and then calling escape_javascript before prepending the data back to the dom.

Here is the rendered javascript response:

$('#repeater').prepend("<textarea class=\"text optional count[20,50]\" cols=\"40\" id=\"editBookForm4fab007b4f9f2503d500018b_book_comment\" name=\"book[comment]\" rows=\"6\">

The javascript is broken because the closing tag for the string is on the next line.

I recommend reverting the previous change to the javascript helper until the above change can be more fully tested.

Edit: Looking at the value passed to the escape_javascript function in the debugger, i see the value is:

<textarea class="text optional count[20,50]" cols="40" id="editBookForm4fab007b4f9f2503d500018b_book_comment" name="book[comment]" rows="6"><haml:newline/></textarea>

Still tracking down why this fails in 3.2.3 but works in 3.2.2. I will open a bug when I figure out exactly what is going on.

What is interesting is the


in between the text area's.


steveklabnik replied May 10, 2012

@joe1chen can you make an issue, please? Comments on commits are likely to get lost. Thanks!

Looking more into this.. looks like I may have been wrong... my problem may have been caused by Pull #5191 or a combination of the two..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment