Closed
Bug 449712
Opened 16 years ago
Closed 16 years ago
CRLF in <textarea> becomes two line breaks when text node splits between CR and LF
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
RESOLVED
FIXED
mozilla1.9.1a2
People
(Reporter: cyanberry, Assigned: mrbkap)
References
Details
(Keywords: html5, testcase)
Attachments
(3 files, 2 obsolete files)
|
58.66 KB,
text/html
|
Details | |
|
2.38 KB,
patch
|
mrbkap
:
review+
mrbkap
:
superreview+
|
Details | Diff | Splinter Review |
|
686 bytes,
patch
|
mrbkap
:
review+
mrbkap
:
superreview+
|
Details | Diff | Splinter Review |
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.
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.
|
||
Comment 3•16 years ago
|
||
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.
|
|
||
Updated•16 years ago
|
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
|
|
||
Updated•16 years ago
|
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
I appended comprehensible test case 2. Look 4096, 4915, 5734, 6553, 7372, 8191, 9010, 9829.
|
||
Comment 6•16 years ago
|
||
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
|
|
||
Comment 7•16 years ago
|
||
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?
|
|
||
Comment 8•16 years ago
|
||
|
Assignee | |
Comment 9•16 years ago
|
||
(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.
|
|
Assignee | |
Comment 10•16 years ago
|
||
Comment on attachment 334343 [details] [diff] [review] Not working We want this no matter what.
Attachment #334343 -
Flags: superreview+
Attachment #334343 -
Flags: review+
|
|
Assignee | |
Comment 11•16 years ago
|
||
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)
|
|
Assignee | |
Comment 12•16 years ago
|
||
Note: the last patch applies on top of attachment 334343 [details] [diff] [review].
|
|
||
Comment 13•16 years ago
|
||
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+
|
|
Assignee | |
Comment 14•16 years ago
|
||
Attachment #334384 -
Attachment is obsolete: true
Attachment #334533 -
Flags: superreview+
Attachment #334533 -
Flags: review+
|
||
Comment 15•16 years ago
|
||
Pushed to mozilla-central: http://hg.mozilla.org/mozilla-central/index.cgi/rev/3c09b73c94ed
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.1a2
|
||
Comment 16•16 years ago
|
||
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!
|
|
Assignee | |
Comment 17•16 years ago
|
||
You can get nightly builds at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ .
You need to log in
before you can comment on or make changes to this bug.
Description
•