Closed
Bug 40394
Opened 24 years ago
Closed 24 years ago
Multiple spaces in textareas lost
Categories
(Core :: Layout: Form Controls, defect, P3)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
M17
People
(Reporter: BenB, Assigned: pollmann)
References
()
Details
(Whiteboard: [nsbeta2-][nsbeta3+] fix in hand)
Attachments
(1 file)
125 bytes,
text/html
|
Details |
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% ----
Updated•24 years ago
|
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Comment 1•24 years ago
|
||
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
Reporter | ||
Comment 2•24 years ago
|
||
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 → ---
Reporter | ||
Comment 3•24 years ago
|
||
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>
Comment 4•24 years ago
|
||
will test this more tomorrow
Comment 5•24 years ago
|
||
setting to m17 and assigning to jfrancis
Assignee: beppe → jfrancis
Status: REOPENED → NEW
Target Milestone: --- → M17
Comment 7•24 years ago
|
||
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
Comment 8•24 years ago
|
||
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
Comment 10•24 years ago
|
||
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
Comment 11•24 years ago
|
||
Eric, please take a look at this. Changing component from "layout" to "HTML form controls".
Assignee: karnaze → pollmann
Component: Layout → HTML Form Controls
Assignee | ||
Comment 12•24 years ago
|
||
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
Assignee | ||
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
*** Bug 41892 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 15•24 years ago
|
||
(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
Reporter | ||
Comment 16•24 years ago
|
||
If you have a fix, then by all means check it in. nsbeta2 nomination.
Keywords: nsbeta2
Comment 17•24 years ago
|
||
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
Comment 18•24 years ago
|
||
Marking nsbeta3+
Whiteboard: [nsbeta2-] fix in hand → [nsbeta2-][nsbeta3+] fix in hand
Assignee | ||
Comment 19•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Comment 20•24 years ago
|
||
Eric, The test case has a bad url: http://blueviper/forms/leadingwhitespace.html Can you please attached this file. Thanks.
Assignee | ||
Comment 21•24 years ago
|
||
Assignee | ||
Comment 22•24 years ago
|
||
Hmm, don't know what happened, but the page is up now - I've attached it too, just in case! :)
You need to log in
before you can comment on or make changes to this bug.
Description
•