3474 - textarea submissions losing newlines

Status: VERIFIED INVALID

(Core :: DOM: Core & HTML, defect, P2)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

When I type enter in a textarea, it isn't being submitted properly.
For example, there is a blank line between each sentence in this submission.
This probably won't work, but if it does, it didn't at the URL above.

Comment 1

[Eric Pollmann]

Did you check in a fix this Kevin?  It works correctly for me in the most recent
builds (could not reproduce at http://blueviper/forms/test.html =>
http://blueviper/forms/testDisplay.cgi?element=TextArea)

I just noticed this is related to bug 1829.  (Windows text widgets need \r\n to
display a linefeed, not just \n) Here's an interesting and annoying fact:
Windows submits %0d%0a to represent a linefeed while unix submits only a %0a.

Communicator seems to have standardized on %0d%0a (I just tried Linux 4.51 and
got this anyhow)  Should we do the same with SeaMonkey?

Comment 2

[Eric Pollmann]

Test from Windows Seamonkey  Blank line \/  Test from Windows Seamonkey  Blank line /\

Comment 3

[Eric Pollmann]

Test

Test

Comment 4

[Eric Pollmann]

The

Comment 5

[Eric Pollmann]

Opps.  What I meant to say was:

The entry reading "Test from Windows Seamonkey  Blank line \/  Test from Windows
Seamonkey  Blank line /\" was submitted before I logged in to bugzilla.  There
was a double line feed between the two "Test from Windows Seamonkey"s

The entry reading "Test

Test" was submitted (also by Windows Seamonkey) after logging into bugzilla.
There was also a double line feed between the two "Test"s.  So the first
submission appears to be a bugzilla bug.

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is being submitted with NN 4.5 before logging into bugzilla.  There
are two blank lines here:


And this is a line.
And this is a line.
(I expect this to work.)

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The problem here has to do with the parsing of attributes.  I'm 80% sure Mozilla
is correct, and Bugzilla is exploiting a bug in all the other browsers.  What's
happening is that bugzilla's login form after submitting info on a bug when
you're not logged in contains all the stuff that you've submitted within the
form, as hidden values.  So, for the above, it had:

<input type=hidden name=assigned_to value="[e-mail]">
<input type=hidden name=component value="Form Submission">
<input type=hidden name=comment value="This is being submitted with NN 4.5
before logging into bugzilla.  There
are two blank lines here:


And this is a line.
And this is a line.
(I expect this to work.)">
<input type=hidden name=form_name value="process_bug">
<input type=hidden name=resolution value="FIXED">
<input type=hidden name=dup_id value="">

I believe Mozilla's behavior is correct, but not sure.

Comment 8

[Hixie (not reading bugmail)]

Mozilla is correct. This was covered by bug #2756. The line breaks in the
value attribute above should be collapsed to spaces.

Here is what HTML4 spec says about the contents of CDATA attributes such as
value, alt, title, href, longdesc...:

 CDATA is a sequence of characters from the document character set and
 may include character entities. User agents should interpret attribute
 values as follows:
  o Replace character entities with characters,
  o Ignore line feeds,
  o Replace each carriage return or tab with a single space.
 User agents may ignore leading and trailing white space in CDATA attribute
 values (e.g., "   myval   " may be interpreted as "myval").

                      from http://www.w3.org/TR/REC-html40/types.html#h-6.2

This bug has spawned bug #4928.

Comment 9

[cpratt]

dbaron, could you please verify this? thanks!

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Verifying invalid.  It is a bug in bugzilla.

It may, however, need to be reconsidered for compatibility mode, but would be
difficult to implement without breaking lots of other stuff, I would think.