Closed
Bug 94386
Opened 23 years ago
Closed 23 years ago
CR/LF problems in textareas
Categories
(Core :: DOM: Editor, defect)
Tracking
()
VERIFIED
INVALID
People
(Reporter: bugzilla, Assigned: kinmoz)
Details
Attachments
(2 files)
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
Reporter | ||
Comment 1•23 years ago
|
||
Reporter | ||
Comment 2•23 years ago
|
||
By the way, this works fine in Netscape 4.08
Comment 3•23 years ago
|
||
It looks like on Windows, NN4.x interprets the carriage returns in your <TEXTAREA> as '\r\n', whereas Mozilla interprets them as '\n' alone. This explains the different results you're getting. Given the strings sent to it by the browser, the String.replace() method of JavaScript is working perfectly in both NN4.x and Mozilla. I will attach a debugging version of your testcase to prove this -
Comment 4•23 years ago
|
||
Comment 5•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
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
Comment 7•23 years ago
|
||
Over to editor....
Assignee: rogerl → beppe
Component: Javascript Engine → Editor
QA Contact: pschwartau → sujay
Comment 9•23 years ago
|
||
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
Comment 10•23 years ago
|
||
I think this may be related to bug 88024 and bug 93549, cc anthony and jfrancis
Comment 11•23 years ago
|
||
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
Reporter | ||
Updated•23 years ago
|
Keywords: 4xp,
mozilla1.0
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Assignee | ||
Comment 13•23 years ago
|
||
This is an intentional difference between 4x and mozilla.
Reporter | ||
Comment 14•23 years ago
|
||
Akkna wrote: "Looks like another regression in the code that sends CRLF instead of LF on form submission." So how come this is invalid?
Assignee | ||
Comment 16•23 years ago
|
||
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++.
Comment 17•23 years ago
|
||
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.
Description
•