Please report any other irregularities here.
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3+) Gecko/20010808 BuildID: 2001080804 Reproducible: Always Steps to Reproduce: 1. Try testcase 2. The desired effect of replacing the text in the textarea does not happend
By the way, this works fine in Netscape 4.08
The debugging version of the testcase shows your strings both before and after the String.replace(), indicating each character of the string, and its character code. From this, you can see: In NN4.7, where the carriage return on Windows is interpreted as '\r\n', you always have either '\r' or '\n' remaining after the String.replace(). In Mozilla, the carriage return is interpreted as '\n' alone. So if you replace '\r', nothing happens; and if you replace '\n', you lose all your carriage returns.
Note: you can use a RegExp like /\r?\n/g. This will replace any ocurrence of '\n' or '\r\n' with the desired value, and therefore will work in both NN4.7 and Mozilla/N6
Over to editor....
Assignee: rogerl → beppe
QA Contact: pschwartau → sujay
See bug 28598, by the way. Looks like \r is not allowed in DOM strings...
As I understand it, this bug is about problems with CR/LFs in textareas.
Assignee: beppe → akkana
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Using the method String.replace(); does not work as expected → CR/LF problems in textareas
Probably not related to those bugs. Looks like another regression in the code that sends CRLF instead of LF on form submission. Eric, didn't you work on that the last time it regressed? If I've erred, my apologies, send it back.
Assignee: akkana → pollmann
Setting default owner -
Assignee: pollmann → kin
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
This is an intentional difference between 4x and mozilla.
Akkna wrote: "Looks like another regression in the code that sends CRLF instead of LF on form submission." So how come this is invalid?
Status: RESOLVED → VERIFIED
I'm not sure why Akkana brought up form submission, perhaps she should comment. After reading this bug, I thought you were reporting about the fact that your JS finds no CRLF pair when looking through the value of the textarea. The reason is because mozilla converts all platform specific line breaks in files it is loading to '\n' ... which prevents us from having to check for platform specific linebreaks throughout our code. The only way to get a \r into a text widget, is to manually add it via JS or C++.
I thought it was about form submission. It's actually about getting the strings in JS, I guess? I don't know what the spec is for line breaks in JS. Definitely in the DOM they're supposed to be newline only.
You need to log in before you can comment on or make changes to this bug.