Closed Bug 25251 Opened 20 years ago Closed 20 years ago

[regression] consecutive spaces in textarea (cause is white-space property not being propogated)

Categories

(Core :: Layout: Form Controls, defect, P1, blocker)

All
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: n-baxley, Assigned: akkzilla)

References

()

Details

(Whiteboard: [PDT-]Have fix, awaiting review)

Attachments

(2 files)

It appears that consecutive spaces entered into a textarea field only show as
one.  I did my testing by sending myself an email from Yahoo.  The spaces show
up in the message after it is sent, but when I'm typing it in, they don't show.
Reassigning to Steve.
Assignee: karnaze → buster
I'm using 5.0 to enter this text in the textfield, with a bunch of spaces
      and they all show up just like I expected.
Severity: normal → blocker
Component: HTML Form Controls → ActiveX Wrapper
Priority: P3 → P1
Hardware: PC → All
Target Milestone: M1
sujay, can you check this out with latest build on NT.  I don't see other...but 
I have Win95.  beppe, what did you use?
QA Contact: ckritzer → sujay
Target Milestone: M1
well shoot, I normally put in all of the info -- I'm on win95, using build
2000012812. I'm inclined to mark it as worksforme
I think I've found the distinction.  It has to do with the wrap attribute.  If 
wrap is Physical or Virtual, the consecutive spaces do not show.  If it is Off, 
Hard, or non-existent, the consecutive spaces do show.  The W3C doesn't even 
have wrap listed as an attribute for textarea, although I don't know why.  
Anyway, that is the difference.  I've attached an example with the different 
scenarios.
I'll look in to yahoo mail specifically, but in general here's the scoop on 
the WRAP attribute.

For backwards compatibility with Nav 4.x, we support the wrap attributes HARD, 
SOFT, and OFF, as described at 
http://developer.netscape.com/docs/manuals/htmlguid/tags10.htm#1340340:

WRAP specifies whether lines longer than the text area's column width wrap to 
the next line. Navigator 2.0. 

The value of WRAP can be one of the following: 

* OFF disables word wrap. Text the user types is displayed with the 
exact line breaks that the user types. If the user explicitly
inserts a line break, however, the break is included as part of the 
text area's value. The user has to scroll horizontally to see the
ends of lines that do not fit in the text area element. 
* HARD causes word wrap, and the line breaks are included when the form 
is submitted. The text wraps inside the text area
element, and that the user does not need to scroll horizontally. 
* SOFT causes word wrap, but the line breaks are not included when the 
form is submitted. 
Status: NEW → ASSIGNED
the identical (hard, soft, off) attributes are also documented for IE at 
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/wrap.asp 
*** Bug 25523 has been marked as a duplicate of this bug. ***
Severity: blocker → major
Component: ActiveX Wrapper → HTML Form Controls
Priority: P1 → P3
copying test case from dup bug 25523:

<HTML>
<TEXTAREA WRAP=PHYSICAL>
</TEXTAREA>
</HTML>

this is the same construct I see in yahoo mail.
There are two problems.  The minor problem is that yahoo mail uses 
microsoft extentions to wrap that we didn't support.  Basically, they used 
"virtual" and "physical" for "soft" and "hard".  We support those now too 
(as soon as I check in.)

The more important problem, which is totally independent, is that the 
style system is broken with respect to it's handling of the white-space 
style on the body.  If I set
    white-space: pre wrap;
it does not propogate correctly.
If I set
    white-space: -moz-pre-wrap; width: 20ch;
it does propogate correctly.

Here's a simple example of the broken state, that does not involve text 
controls:

<html>
<head><style>body { white-space: pre wrap; }</style></head>
<body>a     b (should be several spaces between a and b)</body>
</html>


This is a serious blocker because user of many pages like yahoo mail will not be 
able to use the page effectively. I believe this is a regression, though I don't 
know the last build when it worked correctly.
Assignee: buster → pierre
Severity: major → blocker
Status: ASSIGNED → NEW
Keywords: beta1
Priority: P3 → P1
Summary: consecutive spaces in textarea → [regression] consecutive spaces in textarea (cause is white-space property not being propogated)
"white-space: pre wrap" is not valid code. If you want to display preformatted 
text that wraps, you should use "-moz-pre-wrap" (nsHTMLEditor.cpp, line 3405).

Reassigned to Akkana.
Assignee: pierre → akkana
Accepting.  I have a fix, will check in as soon as Pierre blesses it.
Status: NEW → ASSIGNED
Target Milestone: M14
Whiteboard: Have fix, awaiting review
Putting on PDT- radar for beta1.  Please do check in fix after review, but would 
not hold beta should this reopen.
Whiteboard: Have fix, awaiting review → [PDT-]Have fix, awaiting review
patch looks good.  r=buster
Thanks, Steve!  The fix has been checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
verified in 2/4 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.