Open
Bug 182470
Opened 22 years ago
Updated 2 years ago
\r inside <PRE> </PRE> produces extra line
Categories
(Core :: Layout, defect, P3)
Tracking
()
REOPENED
Future
People
(Reporter: mal, Unassigned)
Details
(Keywords: testcase)
Attachments
(1 file)
178 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003 mozilla-1.0.1-2.7.3, RedHat 7.3 On Linux Mozilla (mozilla-1.0.1-2.7.3, RedHat 7.3) interpretes \r as an extra line in <PRE></PRE> mode. No scuh problem happen with netscape. Reproducible: Always Steps to Reproduce: Check this html <HTML> <BODY BGCOLOR="#ffffff"> NO CR <PRE> --123-- --345-- --567-- </PRE> WITH CR <PRE> --123-- --345-- --567-- </PRE> </BODY> </HTML> Actual Results: Second printing produces extra lines Expected Results: There should be no extra line(s). Netscape shows "WITH CR" and "WITHOUT CR" identically, mozilla adds extra line when rendering.
Comment 1•22 years ago
|
||
mozilla linux trunk build 20021126 displays like this: ----------------------------- NO CR --123-- --345-- --567-- WITH CR --123-- --345-- --567-- ----------------------- Parser?
.
Assignee: block-and-inline → harishd
Component: Layout: Block & Inline → Parser
QA Contact: ian → moied
Comment 3•22 years ago
|
||
Confirming. The effect is still present in linux nightly 2002122708.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: <PRE> </PRE> produces extra line on Linux if text has \r → \r inside <PRE> </PRE> produces extra line
--> Sounds like layout.
Assignee: harishd → other
Component: Parser → Layout
QA Contact: moied → ian
Comment 5•21 years ago
|
||
I see it on Netscape 7.02 and Mozilla on WinXP platform.
OS: Linux → All
Priority: -- → P3
Updated•21 years ago
|
Target Milestone: --- → Future
Comment 6•21 years ago
|
||
*** This bug has been marked as a duplicate of 98356 ***
Status: NEW → RESOLVED
Closed: 21 years ago
QA Contact: ian → petersen
Resolution: --- → DUPLICATE
Comment 7•21 years ago
|
||
This duplication was not correct. Bug 98356 concerns the question of whether a *lone* CR ( ), the Mac-platform-specific linebreaker, should produce a line break in <pre> elements. This bug involves a CR-LF pair, which should be treated as a single line break and is not. Still valid; reopening. Harish, are you sure this isn't parser? IIRC, we're supposed to convert all the platform-specific newlines to LF in parser for layout, and it sounds like that's what's falling down here.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 8•21 years ago
|
||
The problem is that each entity is a separate token... We would need to handle cases like a \r at the end of a text token followed by a entity, etc... That would be quite painful. :( And in DOM3, entities are actually separate nodes. So this "collapse \r and \n" together trick really can't work then. It sounds like the real problem is some layout code that looks for a CR when it really shouldn't.
Comment 9•21 years ago
|
||
Oh, I see the problem. The HTML content sink code converts the \r into a \n when it processes an entity node... So we end up with \n\n in the DOM. Frankly, I'm not sure how we could handle this differently, especially with this whole DOM3 entity DOMNode thing.
Updated•15 years ago
|
Assignee: layout → nobody
QA Contact: chrispetersen → layout
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•