Closed Bug 50633 Opened 24 years ago Closed 22 years ago

textarea always does a soft wrap, even with wrap="off" or white-space:nowrap or white-space:pre

Categories

(Core :: Layout: Form Controls, defect, P3)

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: anthony, Assigned: kinmoz)

References

(Blocks 1 open bug)

Details

(4 keywords, Whiteboard: [CSS1-5.6.2])

Attachments

(8 files, 5 obsolete files)

Test cases showing word wrap dainbramage.
5.12 KB, text/html
Details
testcase using CSS to try to prevent wordwrap
897 bytes, text/html
Details
TEXTAREA wrap does not work as expected when no COL / ROW info specified
2.26 KB, text/html
Details
testacase showing wrap=soft|hard|off|virtual
906 bytes, text/html
Details
Simple TEXTAREA with javascript controls as a test case.
522 bytes, text/html
Details
Test case showing all relevant possibilities
2.34 KB, text/html
Details
Same patch, new file name
1.10 KB, patch
john
: review+
kinmoz
: superreview+
asa
: approval+
Details | Diff | Splinter Review
Textarea testcase testing ALL possible combinations
1.14 KB, text/html
Details 
It seems that textarea always does a soft wrap, even with wrap="off"
set. My understanding is that in this case, the textarea widget should
get a horizontal scrollbar, and not do line wrapping. Certainly this
is how all other browsers I can find behave. I can't seem to get Mozilla
to display a horizontal scrollbar at all.

It seems like this has always been the case - but until now the textarea's
not been useful enough for Zope work to make me notice this.
reassigning
Assignee: rods → beppe
will need to future this one, we will address this next time around
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Keywords: helpwanted
Target Milestone: --- → Future
Updating QA contact.
QA Contact: ckritzer → bsharma
Ok, it looks like this is not going to be as hard as I thought.

It seems like it's the textarea's COLS attribute that forces
the bogus word wrapping behaviour. I'll try to attach an example,
but if bugzilla hates me, it's also available at

http://www.zope.org/Members/anthony/tests/mozilla/textarea

Note the various tests show fairly conclusively that the 'WRAP' is
being overridden by the "cols" setting. Even in the "wrap = soft" and
"wrap = hard" cases, unless the "cols" attribute is also set, it has
no effect.

I'm going to dig into the code a bit, but I've not looked anywhere near this
code yet, so it's going to be ugly. Pointers are welcome.

(I'd also question the milestone 'future' - it seems like this is a fairly
fundamental thing to make textareas useful...?)
I will reassign it to kin, since he is most familiar with textareas, kin please 
readjust milestone as appropriate.
Assignee: beppe → kin
Status: ASSIGNED → NEW
Accepting bug.
Status: NEW → ASSIGNED
QA Contact Update
QA Contact: bsharma → vladimire
*** Bug 45503 has been marked as a duplicate of this bug. ***
OK... this happens not only with wrap="off" but also with white-space:pre and
white-space:nowrap.  Adding keywords, about to attach a testcase.
Keywords: correctness, css1, mozilla1.0, nsbeta1, testcase
OS: Linux → All
Hardware: PC → All
Summary: textarea always does a soft wrap, even with wrap="off" → textarea always does a soft wrap, even with wrap="off" or white-space:nowrap or white-space:pre
This bug is a serious catfood issue for me. I post to newsgroup forums through 
an interface that uses <textarea name=bd wrap=hard rows=11 cols=65></textarea>. 
When I use Mozilla to post to the newsgroup, it looks like a maniac wrote the 
message because of the bizarre line wraps.
This is also serious for me, as it ruins the design of my pages which have HTML
code in a text area. Can you imagine coding with wordwrap turned on?
The problem seems to be in nsGfxTextControlFrame2::CreateAnonymousContent --

  PRInt32 col =-1;
  if (!(colAttr.GetUnit() == eHTMLUnit_Null))
  {
    col = ((colAttr.GetUnit() == eHTMLUnit_Pixel) ? colAttr.GetPixelValue() :
                                                    colAttr.GetIntValue());
    col = (col <= 0) ? 1 : col; // XXX why a default of 1 char, why hide it
  }
  textEditor->SetWrapWidth(col);

nsPlaintextEditor::SetWrapWidth sets "white-space: -moz-pre-wrap" if col is 
greater than zero. If it is /less/ than zero (as it would be if there was no col 
attribute), then it sets "white-space: pre".

i am having trouble with the opposite. Mozilla 0.9.1 doesn't wrap textarea text
if no COLS info is given. 
i wanted to completely format my TEXTAREAS with CSS, that's why i didn't use
COLS/ROWS.

see the attachment i created. it can also be found at @
http://www.phillipoertel.com/temp/moz/textarea_testing_mozilla.html

size and font for TEXTAREAS are specified via CSS.

NOTE: Opera 5.11 and IE5.5 wrap in all of the 4 cases shown

hope this isn't to confusing and i didn't get too confused ;-)
phil!
Note that ROWS and COLS are required attributes for valid HTML 4.01.

Also, the behavior I see in textareas is wrong in that no matter what you set 
the WRAP attribute to, it will always come back as WRAP="soft" - with one 
exception, if you enter a long line into the textbox (longer than the number of 
columns with fixed-width fonts) it will mysteriously transform into a 
WRAP="off" textbox for that one line and start wrapping again later. The 
expected behavior in such a case is for the long line to be visually broken 
into two lines, but still be submitted as one line. Of course none of this 
wrapping should be occurring when WRAP is turned off. Right now textarea 
wrapping is severely broken and I would be ashamed to see another Netscape 
release with this bug.
Keywords: nsCatFood
I see this still happening in build id : 2001-08-02-10-trunk window2000
*** Bug 94166 has been marked as a duplicate of this bug. ***
*** Bug 98902 has been marked as a duplicate of this bug. ***
I see two cases:
1. With no COLS, TEXTAREA never wraps
2. With COLS, TEXTAREA always wraps

I can't tell whether the wrap is hard or soft in case 2
(this bit might actually work as it is not a display issue).
Blocks: 100020
Blocks: 104166
*** Bug 104592 has been marked as a duplicate of this bug. ***
Keywords: nsbeta1
This one merits a relnote.
Keywords: relnote
addition to the comment #21 :-

1. with no COLS defined - the text within the textarea never wraps. the 
horizontal bar is displayed
2. with COLS defined - the text within the textarea wraps always. No horizontal 
bar displayed.

This happens with all the following:-
<textare wrap="hard">
<textare wrap="soft">
<textare wrap="off">
<textare wrap="virtual">
*** Bug 101729 has been marked as a duplicate of this bug. ***
*** Bug 92851 has been marked as a duplicate of this bug. ***
Depends on: 99457
Marking nsbeta1-.
Keywords: nsbeta1 → nsbeta1-
McCluskey: If this change was made because the next beta is in its final stages,
please renominate this bug after the beta goes through (to save me the trouble
from doing it). This is something that *NEEDS* to be in Netscape--it's a
fundamental aspect of form behavior and we've done it the wrong way for too long.
Meh to that. Renominating. If you still think this isn't important enough for
the next Netscape release, I'd like to hear some good reasons why. This behavior
is mandated in the current HTML recommendation, and creates a hassle for users.
Furthermore the previous rejection was made by a user who has no prior
involvement with this bug.
Keywords: nsbeta1- → nsbeta1
I agree, this bug sucks ass for me when using Bugzilla.  I enter a comment, go
to check something, come back, and my comment has hard returns in it.  Kevin
McCluskey is my manager, so he's involved behind the scenes watching these bugs
:)  I plan to re-look at the milestone on this when I've gone through my other
bugs in a few days, we shall see.

On another note, I didn't remember that form state memory was even *in* the
specification, but I know for certain that it's not mandated (I checked when I
was doing my first form patch).

If you're interested in pursuing this patch, just email me, I can give pointers.
> This behavior is mandated in the current HTML recommendation

The hell it is.  the "wrap" attribute is not mentioned anywhere in the HTML
specification and CSS explicitly says that it does not apply to form controls. 
This bug is a major annoyance but a spec-compliance issue it is not.
Bulk moving all nsbeta1 nominations to Moz1.1.  If the nomination is approved it
will be marked nsbeta1+ and moved to the Mozilla1.0 milestone.
Target Milestone: Future → mozilla1.1
Marking nsbeta1-. If we have time jkeiser will try and work on it for
Mozilla1.0, but at this point engineers are overloaded with higher priority bugs.
Keywords: nsbeta1 → nsbeta1-
This patch doesn't recognize soft/hard/virtual/physical settings, but does get
the wrap=off case working.  Bug 41464 is another animal entirely, and the
ultimate solution probably solves both simultaneously.
Bill, could you please use 'diff -u' (or 'cvs diff -u') to create a unified diff
of this patch?  Those are much much easier to review...
Whiteboard: [CSS1-5.6.2]
I think we do support wrap=hard, which means, as I understand it, that the
wrapping that occurs while the user types in the textarea should be sent to the
server as linebreaks, as opposed to the default behavior, where only
user-entered linebreaks should be sent to the server.  I think bugzilla actually
relies on this working, and why bugzilla comments entered with some other
browsers show up as one long line.  wrap=soft is the default, and we clearly
support that.  I'm not sure what wrap=virtual or wrap=physical are -- they're
not described in any of:

http://www.w3.org/TR/html40/interact/forms.html#h-17.7
http://developer.netscape.com/docs/manuals/htmlguid/tags10.htm#1340340
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/wrap.asp

Making wrap be reflected in the DOM should be a separate bug.

It looks like that patch uses tabs instead of spaces -- please stick to spaces.
Also, since you're using it as a boolean, |PRInt32 taFlag| should probably have
type PRBool and be assigned values PR_TRUE or PR_FALSE.  It seems better to call
it something like |isTextarea| (if that's what it means).
The wrap = virtual and wrap = physical attributes are used by Netscape 4. If 
wrap is not specified or set to off, Netscape 4 leaves long lines as is. This 
has the unfortunate effect of creating horizontal scrollbars. Because of this, 
almost every page written for Netscape 4 uses wrap=virtual. Wrap=virtual says 
that long lines should be displayed with line breaks but transmitted without 
(except for user inserted breaks - equivalent to wrap=soft?) and wrap=physical 
says that long lines should be displayed and sent with line breaks included 
(wrap=hard?).
> wrap=physical says that long lines should be displayed and sent with line
> breaks included (wrap=hard?).

One would think.... :)  See bug 77110, however.  IE, NS4/Windows, and NS4/Unix,
at least, treat wrap=physical the same as wrap=virtual, the same as wrap=soft.
Following David Baron's suggestions in Comment 38 and 39, redeclared the flag
variable, eliminated tabs, and removed uneccessary whitespace changes.
*** Bug 135100 has been marked as a duplicate of this bug. ***
also seeing soft wrap with wrap="off" in windows 2000
Holy purple garbonzos man, what browser were you using (and what version if us)?
 You removed the entire CC list.
*** Bug 148956 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1alpha → Future
Comment on attachment 74514 [details] [diff] [review]
Cleaned up patch to get wrap=off working.

Please check type == NS_FORM_TEXTAREA rather than adding the isTextarea bool.

Need short comment explaining what it is doing--that it is ignoring cols when
wrap=soft.

NS_CONTENT_ATTR_NOT_THERE != rv ... switch to rv != NS_CONTENT_ATTR_NOT_THERE

Also, what happens when you set wrap via JS?  Does it work?  Did it work
before?
Isn't that patch depending on a bug?  (bug 119915 to be exact).
Added a simple test case with javascript wrapping control.
This incorporates jkeiser's suggested changes.	Changing the wrap attribute
with DOM is unsuccessful, as it is before the patch.
Attachment #71296 - Attachment is obsolete: true
Attachment #71425 - Attachment is obsolete: true
Attachment #74514 - Attachment is obsolete: true
Each textarea has a different initial setting of the wrap attribute and a means
to change it with javascript. There is no difference between soft, hard, and
undefined with or without the patch.  Off is like the others without the patch
but does not wrap with the patch.  Changing any of them with javascript does
nothing at all (both without and with the patch).
Each textarea has a different initial setting of the wrap attribute and a means
to change it with javascript. There is no difference between soft, hard, and
undefined with or without the patch.  Off is like the others without the patch
but does not wrap with the patch.  Changing any of them with javascript does
nothing at all (both without and with the patch).
Comment on attachment 93041 [details]
Test case showing all relevant possibilities

Sorry about that. I double-submitted.
Attachment #93041 - Attachment is obsolete: true
Attachment #93041 - Attachment is patch: false
Attachment #93041 - Attachment mime type: text/plain → text/html
They renamed that file out from under my patch.  This is the same patch, but
for the new file name.
Attachment #93040 - Attachment is obsolete: true
Comment on attachment 93054 [details] [diff] [review]
Same patch, new file name

r=jkeiser
Attachment #93054 - Flags: review+
Comment on attachment 93054 [details] [diff] [review]
Same patch, new file name

This patch still doesn't address:

1. The problem with the CSS white-space property mentioned in the summary.

2. The fact that the wrap value can be changed realtime.

That all said, and the fact that I know the method we use to force wrapping in
the text widgets need to be reworked, I'm going to sr=kin@netscape.com this
change because I know it covers the "set it and forget it" case which is most
commonly used, and I'm not going to have the cycles any time soon to address
this properly.

After checkin, leave this bug open, or file 2 separate bugs about the 2 issues
mentioned above.
Attachment #93054 - Flags: superreview+
i've sent an email to drivers@mozilla.org. hopefully this can go in ASAP before 
mozilla 1.1 final is out.

Comment on attachment 93054 [details] [diff] [review]
Same patch, new file name

a=asa (on behalf of drivers) for checkin to 1.1
Attachment #93054 - Flags: approval+
checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
i've split the rest of this bug into two different bugs :
bug# 159981 - white-space:nowrap or white-space:pre dont work
bug# 159979 - textarea wrapping controls dont work with javascript

all of my problems have been solved with the patch included in
this bug report so if anyone here wishes to pursue it further,
use the two bugs referenced above. i wont be active in getting either of
those resolved -- they dont concern me significantly. thanks.
All right, everyone who tested this patch made a SERIOUS error. Now the behavior
is reversed: If rows/cols info is provided, it works correctly, if not,
textareas are NEVER wrapped. Attaching a complete testcase.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Skewer, you are talking about bug 119915 which bz mentioned above. It's been a
bug for a long time, even prior to the checkin of attachment 93054 [details] [diff] [review].
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
I don't understand how that became a seperate issue from this bug, but if
nothing has regressed, there's no problem.
QA Contact: vladimire → tpreston
why is this marked 'RESOLVED FIXED'?  this is NOT fixed in 1.0.1, or am i
missing something?
this bug, combined with bug 80341, make Mozilla and K-Meleon WORTHLESS for
developers who edit code templates via html forms.
rob johnson :
please download 1.1 and try it out. This bug is fixed in 1.1 final and 
is therefore marked resolved - fixed.
if you want to bitch/whine about how it was fixed go to 

bug# 159981 - white-space:nowrap or white-space:pre dont work
bug# 159979 - textarea wrapping controls dont work with javascript

and submit patches or whatever.


Rob: 1.0.1 is based on 1.0, which branched from the trunk in _April_.  In other
words it's ancient code that is maintained for embeddors who really want
stability.  The only fixes going into that branch are critical security fixes.
my bad, the mozilla.org news announces "Mozilla 1.0.1 Release" so i mistakenly
thought this was the most recent release.  sorry.
Blocks: 212456
This bug (tested with white-space:nowrap) seems to be present in Firefox 1.0.7. Please fix.
That's bug 82711, not this bug.  And if you want it fixed, chances are you'll have to do it yourself or pay someone to do it.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: