Closed Bug 449712 Opened 11 years ago Closed 11 years ago

CRLF in <textarea> becomes two line breaks when text node splits between CR and LF

Categories

(Core :: HTML: Parser, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla1.9.1a2

People

(Reporter: cyanberry, Assigned: mrbkap)

References

Details

(Keywords: html5, testcase)

Attachments

(3 files, 2 obsolete files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.2) Sleipnir/2.8.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

The line feed code(CRLF) increases if the textarea is seen in a browser.

For examples.

* HTML Source
----
<html><body><TEXTAREA rows="20" cols="120">ab
ab
ab
ab
ab
......(a lot of "ab\r\n")
</TEXTAREA></body></html>
----

* If the textarea is seen in a browser, the line only of the line feed code has increased. 
at line 4097, 5463, 6829, 8195, 9561...
The difference is all 1366 lines. 


Reproducible: Always

Steps to Reproduce:
1.The HTML source that contains textarea that a lot of line feed codes(CRLF) is displayed by a browser. 
Actual Results:  
the line feed code increase in textarea displayed by a browser.

Expected Results:  
It is displayed according to the HTML source.
Attached file Test case (obsolete) —
Because DOM Inspector was seen, it noticed. 

It seems to have been divided by 4096 bytes per 1 text node of the text area, and the line feed code seems to have been treated as 1 byte at this time. 

Therefore, when the 4096th byte is CR and the first byte of the following text node is LF, it is likely to be output as a separate changing line. 
Firefox creating multiple text nodes is bug 194231.  Clearly, there's another bug here as well, but I'm having trouble creating a testcase for it that doesn't involve bug 194231.
Summary: The line feed code(CRLF) increases if the text area is seen in a browser → CRLF in <textarea> becomes two line breaks when text node splits between CR and LF
Component: General → Layout: Form Controls
Keywords: testcase
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout.form-controls
Hardware: PC → All
Version: unspecified → Trunk
Attachment #332900 - Attachment is obsolete: true
Attached file Test case 2
I appended comprehensible test case 2. 
Look 4096, 4915, 5734, 6553, 7372, 8191, 9010, 9829.
The parser is creating two consecutive newlines at that point.  Most likely because the \r is at the end of one call to SinkContext::AddText while the \n is at the beginning of the next call...
Status: UNCONFIRMED → NEW
Component: Layout: Form Controls → HTML: Parser
Ever confirmed: true
Keywords: html5
QA Contact: layout.form-controls → parser
Well, I can confirm that if I always pass a PR_TRUE as the last arg to CopyNewlineNormalizedUnicodeTo, then the problem goes away.  But the obvious patch that I thought would fix this doesn't work.  I'll attach it just in case I missed something glaringly obvious.

Oh, and taking out the setting to PR_FALSE in that patch in FlushText doesn't help either.  Are we actually creating new SinkContexts here?
(In reply to comment #7)
> Oh, and taking out the setting to PR_FALSE in that patch in FlushText doesn't
> help either.  Are we actually creating new SinkContexts here?

I added a debug printf in SinkContext::AddText ... we're only getting one call to AddText here (which is expected), so no multiple context involved.
Comment on attachment 334343 [details] [diff] [review]
Not working

We want this no matter what.
Attachment #334343 - Flags: superreview+
Attachment #334343 - Flags: review+
Attached patch Fix for this bug (obsolete) — Splinter Review
And here's the fix. It took me *way* too long to notice this. The problem is that currently, when we flush with isLastCharCR == PR_TRUE, we'll fall through and do a 0-length write, which clears isLastCharCR. Now, we'll not do that 0-length write, but instead continue writing the newline that awaits.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #334384 - Flags: superreview?(bzbarsky)
Attachment #334384 - Flags: review?(bzbarsky)
Note: the last patch applies on top of attachment 334343 [details] [diff] [review].
Comment on attachment 334384 [details] [diff] [review]
Fix for this bug

Duh.  Add a lengthier comment saying that we need to avoid calling CopyNewlineNormalizedUnicodeTo so it won't clobber mLastTextCharWasCR, and looks great.
Attachment #334384 - Flags: superreview?(bzbarsky)
Attachment #334384 - Flags: superreview+
Attachment #334384 - Flags: review?(bzbarsky)
Attachment #334384 - Flags: review+
Attachment #334384 - Attachment is obsolete: true
Attachment #334533 - Flags: superreview+
Attachment #334533 - Flags: review+
Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/index.cgi/rev/3c09b73c94ed
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
Has this bug been fixed?  I use large text areas where it's critical that extra lines do not get added, and just tore out much hair wondering where those newlines were coming from.

If it's been fixed, where can I get a nightly build or something similar for Windows XP?

Thanks!
Blocks: 466957
You need to log in before you can comment on or make changes to this bug.