94386 - CR/LF problems in textareas

Status: VERIFIED INVALID

(Core :: DOM: Editor, defect)

Description

[José Jeria]

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

Comment 1

[José Jeria]

Attachment: Try this attachment to see the error

Comment 2

[José Jeria]

By the way, this works fine in Netscape 4.08

Comment 3

[Phil Schwartau]

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

[Phil Schwartau]

Attachment: Same testcase, with debugging code added -

Comment 5

[Phil Schwartau]

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

[Phil Schwartau]

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

[Boris Zbarsky [:bzbarsky]]

Over to editor....

Comment 8

[Boris Zbarsky [:bzbarsky]]

See bug 28598, by the way.  Looks like \r is not allowed in DOM strings...

Comment 9

[Simon Fraser [no longer active]]

As I understand it, this bug is about problems with CR/LFs in textareas.

Comment 10

[rubydoo123]

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

Comment 11

[Akkana Peck]

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.

Comment 12

[Phil Schwartau]

Setting default owner - 

Comment 13

[kinmoz]

This is an intentional difference between 4x and mozilla.

Comment 14

[José Jeria]

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

[sujay]

verified.

Comment 16

[kinmoz]

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

[Akkana Peck]

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.