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

VERIFIED FIXED in mozilla0.9.2



18 years ago
18 years ago


(Reporter: phil, Assigned: bzbarsky)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



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

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

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

Comment 3

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

18 years ago
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"
Ever confirmed: true
Keywords: 4xp, mozilla0.9.1
OS: Windows 2000 → All
Hardware: PC → All

Comment 5

18 years ago
Created attachment 31897 [details] [diff] [review]
patch to make wrap="physical" act like wrap="soft"

Comment 6

18 years ago
Rod?  What do you think?
Keywords: patch, review

Comment 7

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


18 years ago
Target Milestone: --- → mozilla0.9.2

Comment 8

18 years ago
Assignee: rods → bzbarsky
Keywords: review → approval

Comment 9

18 years ago
Marc, could you sr?

Comment 10

18 years ago


18 years ago
Whiteboard: need a=


18 years ago
Blocks: 83989
a=blizzard for drivers for the trunk

Comment 12

18 years ago
fix checked in.
Last Resolved: 18 years ago
Keywords: approval
Resolution: --- → FIXED
Whiteboard: need a=

Comment 13

18 years ago
verifying on build 2001-06-13-09-trunk windows 98
You need to log in before you can comment on or make changes to this bug.