77110 - Textareas with wrap set to physical include extra line feeds on form submission

Status: VERIFIED FIXED

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

Description

[Philip Hagen]

In forms that have a textarea with the "wrap" attribute set to "physical", when
the form information is submitted, extra line feeds (\r\n on Windows machines)
are included at the end of every line, even if the text was merely wrapping due
to the "physical" setting for the "wrap" attribute, and not because any type of
hard return had been entered.  This causes problems for CGI programs or other
programs that may be parsing the submitted form information for certain blocks
of text, especially if these unwanted line feeds are translated into some other
character by the parsing program, as is often the case.  Previous versions of
Netscape (such as 4.x) and Internet Explorer do not add these unwanted line feed
characters at the end of each line of text in the textarea unless an actual hard
return was entered.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I thought the whole point of wrap="physical" was that the \r\n would be
inserted... I certainly recall NS 4.x inserting the \r\n.  If you want it to
look like the text is wrapping but for returns not to be inserted, you want
wrap="virtual", no?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Perhaps a better question.  What is the difference between wrap="physical" and
wrap="virtual" ?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Comments from reporter:

Regarding your questions, I'm not sure if the "wrap" attribute for the
"textarea" tag is valid HTML anymore (which may cause you to ask why I
filed this report, but I'll get to that later), but I do know that the
"wrap" attribute was added as a Netscape extension in version 2.0.  In
older versions of Netscape, such as 4.x, setting wrap="physical" or
wrap="virtual" caused the text in a textarea box to wrap around even
when the user hadn't entered a hard return, whereas not setting the
"wrap" attribute at all caused the text in the textarea box to scroll
all the way to the right until the next hard return, which was less
convenient for the user because they would then have to scroll back and
forth using an additional scroll bar at the bottom of the textarea box.
In IE 5.x and Mozilla, this does not happen, even when the "wrap"
attribute is not defined, and this is probably the correct behavior.
It's certainly more convenient for the end user at least.  Also, in my
testing, setting wrap="physical" did not cause Netscape 4.x to
automatically insert hard returns (new line characters such as /r/n)
into the lines where they were being wrapped to fit within the textarea
box.  It only included the line feed characters at the end of lines
where there were actual hard returns (I can send you an example if you
want).  IE does not do this either.  However, as I mentioned in the bug
report, Mozilla *does* do this, which causes problems for CGI programs
or other programs that are parsing the incoming form data from the
textarea box for certain strings, because now these strings will have
the extra new line characters (or whatever characters the CGI program
may have replaced them with) contained within those lines.  This is why
I mentioned above that even if the "wrap" attribute is deprecated HTML
(I'm not sure of this, but I didn't see it in the HTML 4.01 specs),
there are millions of legacy forms and textarea boxes on the web that
still use this attribute, so if Mozilla is to work properly for and be
accepted by the average user, it needs to handle these textarea boxes
and their legacy "wrap" code properly.  If the "wrap" attribute is truly
deprecated, then perhaps Mozilla should just ignore it and treat all
textarea boxes as if they don't have this attribute, because in my
testing, at least, when I removed that attribute, Mozilla handled the
incoming form data from that textarea box properly.

I hope this helps.  If you want me to set up a demo for you to see all
of this, please let me know.  Thank you.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Philip, you can add comments to this bug by going to
http://bugzilla.mozilla.org/show_bug.cgi?id=77110 and filling in the comments. 
If you _could_ set up a page where this could be tested, that would be great.

I've done a bit of poking around and it looks like initially wrap="physical" was
supposed to be just like wrap="hard".  However, neither IE nor NS 4.x treat it
that way -- they both treat it like wrap="soft".  Since WRAP has never been part
of any HTML spec, all we have to go on is backwards-compatibility... and that
would be to treat wrap="physical" like wrap="soft"

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: patch to make wrap="physical" act like wrap="soft"

Comment 6

[Boris Zbarsky [:bzbarsky]]

Rod?  What do you think?

Comment 7

[Boris Zbarsky [:bzbarsky]]

There is a form where various browsers' treatment of wrap=physical can be tested
at http://www.e-classifieds.net/cgi-bin/test/mozilla/test.cgi

Comment 8

[timeless]

r=timeless

Comment 9

[Boris Zbarsky [:bzbarsky]]

Marc, could you sr?

Comment 10

[Marc Attinasi]

sr=attinasi

Comment 11

[Christopher Blizzard (:blizzard)]

a=blizzard for drivers for the trunk

Comment 12

[Boris Zbarsky [:bzbarsky]]

fix checked in.

Comment 13

[Vladimir Ermakov]

verifying on build 2001-06-13-09-trunk windows 98