bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

CR/LF problems in textareas

VERIFIED INVALID

Status

()

Core
Editor
VERIFIED INVALID
17 years ago
17 years ago

People

(Reporter: José Jeria, Assigned: kinmoz)

Tracking

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
Created attachment 45141 [details]
Try this attachment to see the error
(Reporter)

Comment 2

17 years ago
By the way, this works fine in Netscape 4.08

Comment 3

17 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

17 years ago
Created attachment 45149 [details]
Same testcase, with debugging code added -

Comment 5

17 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

17 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
Over to editor....
Assignee: rogerl → beppe
Component: Javascript Engine → Editor
QA Contact: pschwartau → sujay
See bug 28598, by the way.  Looks like \r is not allowed in DOM strings...

Comment 9

17 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

17 years ago
I think this may be related to bug 88024 and bug 93549, cc anthony and jfrancis

Comment 11

17 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

17 years ago
Keywords: 4xp, mozilla1.0

Comment 12

17 years ago
Setting default owner - 
Assignee: pollmann → kin
(Assignee)

Updated

17 years ago
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Assignee)

Comment 13

17 years ago
This is an intentional difference between 4x and mozilla.
(Reporter)

Comment 14

17 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?

Comment 15

17 years ago
verified.
Status: RESOLVED → VERIFIED
(Assignee)

Comment 16

17 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

17 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.