Closed Bug 40394 Opened 24 years ago Closed 24 years ago

Multiple spaces in textareas lost

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: BenB, Assigned: pollmann)

References

()

Details

(Whiteboard: [nsbeta2-][nsbeta3+] fix in hand)

Attachments

(1 file)

The server (propably) sends a textarea with a line starting with multiple
spaces. Mozilla ignores them.

This messes up Wiki pages. They have e.g. 3 spaces at the beginning of a line
and before a star to denote a li of ul. If you click "Edit this page", the 3
spaces will be lost. If you save, the li will be lost as well - the page is
messed up.

See URL above for a testcase. The initial content is:

Test for Mozilla bug.

3 spaces + star = li of ul
an ul:
   * bla li 1
   * bla li 2
end of ul.

----
*Related pages:* %Unclassified%
----
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
adding spaces or   in front of a list item is not a valid method for 
indentation. If you are attempting to indent the list marker try using the CSS 
value: style="padding-left: 1em" within the parent UL or OL
beppe, you misunderstood my description: Wiki converts such spaces + "*" into an
ul > li. Maybe my first paragraph was wrong, too. Anyway, something here is
wrong (either with Mozilla or Wiki). REOPENing.

Reproduction:
1. Open the URL
2. Click "Edit this page" on the left
3. Click "Save changes"
4. Click "Edit this page" on the left again

Actual result:
Textarea contains

Test for Mozilla bug.

3 spaces + star = li of ul
an ul:
* bla li 1
* bla li 2
end of ul.

----
*Related pages:* %Unclassified%
----

Expected result
Textarea contains

Test for Mozilla bug.

3 spaces + star = li of ul
an ul:
   * bla li 1
   * bla li 2
end of ul.

----
*Related pages:* %Unclassified%
----

(just like with 4.x).
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
BTW: after 1., you shouidl see something like teh result of

Test for Mozilla bug.
<p> 
3 spaces + star = li of ul.
an ul:
<UL>
<LI> bla li 1
<LI> bla li 2
</UL>
end of ul.
<p> 
<HR>
<STRONG>Related pages:</STRONG> <A
href="http://www2.berlin-consortium.org/wiki/html/Berlin/Unclassified.htm">Unclassified</a>
<HR>
will test this more tomorrow
setting to m17 and assigning to jfrancis
Assignee: beppe → jfrancis
Status: REOPENED → NEW
Target Milestone: --- → M17
accepting bug
Status: NEW → ASSIGNED
the url is dead.  But that doesnt matter.  The problem, as I understand it, is 
that leading whitespace is not being honored in textareas.  I have verified that 
this is the case, and that it is honored in 4.x.

I checked the string being passed to the editor, and it already has the leading 
whitespace gone.  I suspect layout is incorrectly stripping leading whitespace in 
the circumstance.  Assigning to layout.

Layout folks: An easy way to see the situation is to set a breakpoint on 
nsHTMLEditor::InsertText(), and load the following document in mozilla:
<html><head></head><body><textarea>   * test</textarea></body></html>

You will see that the string passed to InsertText is just "* test".
Component: Editor → Layout
reassigning
Assignee: jfrancis → clayton
Status: ASSIGNED → NEW
QA Contact: sujay → petersen
Here is the problem ( snippet from LXR ):

NS_IMETHODIMP
411               nsHTMLTextAreaElement::SetDefaultValue(const nsString& 
aDefaultValue)
412               {
413 sfraser  1.36   // trim leading whitespace. -- why?
414 karnaze  1.6    static char whitespace[] = " \r\n\t";
415 sfraser  1.36   nsString defaultValue(aDefaultValue);
416                 defaultValue.Trim(whitespace, PR_TRUE, PR_FALSE);
417               .....

Over to Simon.
Assignee: clayton → sfraser
I didn't add that code to strip whitespace; it was there before (i may have 
reformatted those lines):
<http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/html/content/src/
nsHTMLTextAreaElement.cpp&rev=1.35&root=/cvsroot>

karnaze added those lines to strip whitespace in version 1.35.
Maybe this is related to bug 1132?

Assignee: sfraser → karnaze
Eric, please take a look at this. Changing component from "layout" to "HTML 
form controls".
Assignee: karnaze → pollmann
Component: Layout → HTML Form Controls
Okay, from what I read above, for backwards compatability we should not be 
collapsing or trimming whitespace.  Not sure what the spec says we should be 
doing in standards mode.  I'll check it out.
Status: NEW → ASSIGNED
What Nav and IE do is in line with the spec.  Trim the first character iff it is 
a linebreak.  I have a fix for this in hand, which will also fix this bug.
Whiteboard: fix in hand
*** Bug 41892 has been marked as a duplicate of this bug. ***
(updating mutiple bugs)

Nominating this bug for beta3 because it is either a crasher or a correctness 
bug and I have a straightforward fix in hand.  This bug fix is small, low risk, 
and can easily be reverted with no side effects.
Keywords: nsbeta3
If you have a fix, then by all means check it in. nsbeta2 nomination.
Keywords: nsbeta2
Putting on [nsbeta2-] radar. Not critical to beta2.  Adding "nsbeta3" keyword 
for consideration of a fix for that milestone. 
Whiteboard: fix in hand → [nsbeta2-] fix in hand
Marking nsbeta3+
Whiteboard: [nsbeta2-] fix in hand → [nsbeta2-][nsbeta3+] fix in hand
Fix checked in.  To verify, go to this URL:

http://blueviper/forms/leadingwhitespace.html

The textarea should contain a blank line, then three spaces, then the word 
"test", then another blank line.  (Before it contained the word "test" on the 
first line with no leading spaces.  That was wrong.)

Thanks, Harish for narrowing down exactly where the fix needed to go!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
Eric, 

The test case has a bad url:

http://blueviper/forms/leadingwhitespace.html

Can you please attached this file. Thanks.
Hmm, don't know what happened, but the page is up now - I've attached it too,
just in case!  :)
Marking verified in the Sept 7th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: