Develop Reference

Cross-Browser - Newline characters in textareas

In my web application (JSP, JQuery...) there is a form which, along with other fields, has a textarea where the user can input notes freely. The value is saved to the database as is.
The problem happens when the value has newline characters and is loaded back to the textarea; it sometimes "breaks" the Jquery code. Explaining further:
The value is loaded to the textarea using Jquery:
$('#p_notas').text("value_from_db");
When the user hits Enter to insert a new paragraph, the resulting value will include a newline character (or more than one char). This char is the problem as it varies from browser to browser and I haven't found out which one is causing the problem.
The error I get is a console error: SyntaxError: unterminated string literal. The page doesn't load correctly.
I'm not able to reproduce the problem. I tried with Chrome, Firefox and IE Edge (with several combinations of user agent and document mode).
We advise our users to use IE8+, Firefox or Chrome but we can't control it.
What I wanted to know is which character is causing the problem and how can I solve it.
Thanks
EDIT: Summing up - What are the differences in newline characters for the different browsers? Can I do anything to make them uniform?
EDIT 2: Looking at the page in the debugger, what I get is:
Case 1 (No problem)
$('#p_notas').text("This is the text I inserted \r\n More text");
Case 2 (Problem)
$('#p_notas').text("This is the text I inserted
More text");
In case 2 I get the Javascript error "SyntaxError: unterminated string literal." because it is interpreted as two lines of code
EDIT 3: #m02ph3u5 I tried using '\r' '\n' '\r\n' '\n\r' and I couldn't reproduce the problem.
EDIT 4: I'm going to try and replace all line breaks with '\n\r'
EDIT 5: In case it is of interest, what I did was treat the value before it was saved
value.replace(/(?:\r\n|\r(?=\n)|\n(?=\r))/g, '\n\r')

The problem isn't the browser but the operating system. Quoting from this post:
So, using \r\n will ensure linebreaks on all major operating systems
without issue.
Here's a nice read on the why: why do operating systems implement line breaks differently?
The problem you might be experiencing is saving the value of the textarea and then returning that value including any newlines. What you could do is "normalize" the value before saving, so that you don't have to change the output. In other words: get the value from the textarea, do a find-and-replace and replace every ossible occurrence of a newline (\r, \n) by a value that works on all OS's \r\n. Then, when you get the value from the database later on, it'll always be correct.

I suspect your problem is actually any new line in the entered input is causing an issue. It looks like on the server you are have a templated page something like:
$('#p_notas').text("<%=db.value%>");
So what you end up with client side is:
$('#p_notas').text("some notes that
were entered by the user");
or some other characters that break the JS. Embedded quotes would do it too.
You need to escape the user entered values some how. The preferred "modern" way is to format info you are returning as AJAX. If you are embedding the value within a template what I might do is:
<div style="display:none" id="userdata><%=db.value%></div>
<script>$('#p_notas').text($("#userdata").text());</script>
Of course if it were this exactly you could just embed the data in the text area <textarea><%=db.value%></textarea>

When you output data to the response, you always need to encode it using the appropriate encoding for the context it appears in.
You haven't mentioned which server-side technology you're using. In ASP.NET, for example, the HttpUtility class contains various encoding methods for different contexts:
HtmlEncode for general HTML output;
HtmlAttributeEncode for HTML attributes;
JavaScriptStringEncode for javascript strings;
UrlEncode for values passed in the query-string of a URL;
In some cases, you might need to encode the value more than once. For example, if you're passing a value in a URL via a javascript string, you'd need to UrlEncode the raw value, then JavaScriptStringEncode the result.
Assuming that you're using ASP.NET, and your code currently looks something like this:
$('#p_notas').text("<%# Eval("SomeField") %>");
change it to:
$('#p_notas').text("<%# HttpUtility.JavaScriptStringEncode(Eval("SomeField", "{0}")) %>");

string.substring(1) give different results on different sites with same html

I'm using substring(1) to get the last character off of an href attribute.
I'm talking javascript. On my development site, everything works great and the href http://www.mysite.come/page/#B returns B and all is well.
On the live version of the site, the same substring(1) on the same href returns ttp://www.mysite.com/page/#B - it takes off the first character and returns the rest.
I have no idea why it does this. I've used this same script on multiple sites with no issues. The only thing possibly related is that the dev site is running a newer version of jquery (1.8.1) and the live is on 1.7.1.
I used substr(-1,1) instead and everything works fine, but I'd like to know if someone can tell me why I got 2 different results from the same input.
Thanks!
Extra Info
I've been using the OrganicTabs script from CSS Tricks for a while now (http://css-tricks.com/organic-tabs/) and never had a problem with it until recently. I tracked it down to the substring line:
var curList = base.$el.find("a.current").attr("href").substring(1)
An example of one of the links I'm this script is targeting:
I have modified the script to use substr instead, but I don't know why I would get inconsistent results with substring.

The href you are reading locally, is storing only the hash part of the url,
while for some reason the Live website href's have the whole url
Link vs Link
The substring function is working as expected, since substring(1) should return everything but the first character.
Check how you generate your urls
EDIT: The best solution is to get the substring starting from the hash (excluding it), which covers both cases, as well as cases where the hash is longer than 1 character
href.substring(href.indexOf("#")+1)

String.prototype.substring(n [,...]) returns the first n characters from the string if n is positive, not the last. You need substr(-1) for this.
See:
MDN: substr vs. substring

xss javascript protection

So i am using the jQuery UI library to open new dialog windows, when the new dialog windows are opened I am passing some parameters like this
open modal
The site works fine and no issues at all, my custompage.html just picks up those values that were passed and they are being used on the page, something like this:
var a = customfunctionget(param1); var b = customfunctionget(param2)....
I just received a report that we are vulnerable to Cross-Site Scripting attacks by replacing any of the params with something like this:
><script>alert(123)</script><param
Which I understand correctly what is supposed to happen but on any browser that I try to inject the script the alert is never displayed so the "script/injection" is not being processed, the custompage.html stops working as expected since we need the values to be entered correctly but there is nothing I can do on that respect.
Is there a magic pill that I am missing here? Most of the XSS information that I find does the same thing, try to inject an alert through a tag but other than me denying to display any content if the parameter is not well formed I dont know what else can be done.
Any recommendations, tutorials welcome.

One of the easiest things you can encode all <, >, and & characters with <, >, and &, respectively. Whenever a browser sees a <something> it thinks its a dom element. If you encode those characters, the browser will actually display them. This will foil people trying to execute <script>badstuff</script> on your site.
Note that people won't be able to do things like add <b> tags to things if you do this.
The above suggestion is a first step, but is by no means exhaustive.
I just found this, which seems like a good guide.

There is encodeURIComponent() function in Javascripts to encode special characters to avoid inserting scripts

Javascript Special Characters coming back incorrectly

There is a page where I have certain special characters on and when retrieving values of these via javascript I am getting an odd conversion. The character 'Œ' is coming back as 'R' and its lower case version 'œ' is coming back as 'S'. Is this a limitation of javascript or could it possibly be the browser. This is from testing in firefox. Also this is being retrieved via a repl client (Jssh/MozRepl) so it seems that it could be an issue with these clients themselves rather than the browser.

You likely have an encoding problem somewhere. There are many opportunities to mis-handle the encoding of text. If you post some code, we might be able to help you find it.

Output streams aren't scriptably safe for non-ASCII characters so you will need to wrap the stream in a nsIBinaryOutputStream, a nsIUnicharOutputStream or a nsIConverterOutputStream.

nested quotes in javascript

A bit of a noob question here...
I have a javascript function on a list of table rows
<tr onclick="ClosePopup('{ScenarioID}', '{Name}');" />
However, the {Name} value can sometimes contain the character "'" (single quote). At the moment the error Expected: ')' comes up as a result because it is effectivly ending the javascript function early and destroying the syntax.
What is the best way to prohibit the single quotes in {Name} value from effecting the javascript?
Cheers!

You're committing the first mortal sin of insecure web template programming - not escaping the content of the values being rendered into the template. I can almost guarantee you that if you take that approach, your web app will be vulnerable to XSS (cross site scripting) and any third party will be able to run custom javascript in your page, stealing user data and wreaking havoc as they wish.
Check it out. http://en.wikipedia.org/wiki/Cross-site_scripting
The solution is to escape the content. And to do that properly in the javascript, which is also inside html, is a lot more than just putting escape sequences in front of backslashes.
Any decent templating engine out there should provide you a way to escape content as it's written to the template. Your database values can be left as-is, the important part is escaping it at output time. If your template engine or dynamic web app framework doesn't allow for this, change to one that does. :)

In support of the prior comment please read the following to gain a better understanding of why the security advice is so important.
http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_web_based_attacks_03-2009.en-us.pdf

I would think that you could kill just about any code injection by, for example, replacing
"Hello"
with
String.fromCharCode(72,101,108,108,111)

Although the security information provided by everyone is very valuable, it was not so relevant to me in this situation as everything in this instance is clientside, security measures are applied when getting the data and rendering the XML. The page is also protected through windows authentication (adminsitration section only) and the web app framework cannot be changed. The answer i was looking for was really quite simple in the end.
<tr onclick='ClosePopup("{ScenarioID}", "{Name}");' />