Open Bug 182470 Opened 22 years ago Updated 2 years ago

\r inside <PRE> </PRE> produces extra line

Categories

(Core :: Layout, defect, P3)

Other
All
defect

Tracking

()

REOPENED
Future

People

(Reporter: mal, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

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--&#10;--345--&#10;--567--&#10;
</PRE>

WITH CR
<PRE>
--123--&#13;&#10;--345--&#13;&#10;--567--&#13;&#10;
</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.
Attached file reporter's testcase
mozilla linux trunk build 20021126 displays like this:
-----------------------------
NO CR

--123--
--345--
--567--


WITH CR

--123--

--345--

--567--
-----------------------

Parser?
Keywords: testcase
.
Assignee: block-and-inline → harishd
Component: Layout: Block & Inline → Parser
QA Contact: ian → moied
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
I see it on Netscape 7.02 and Mozilla on WinXP platform.
OS: Linux → All
Priority: -- → P3
Target Milestone: --- → Future

*** This bug has been marked as a duplicate of 98356 ***
Status: NEW → RESOLVED
Closed: 21 years ago
QA Contact: ian → petersen
Resolution: --- → DUPLICATE
This duplication was not correct. Bug 98356 concerns the question of whether a
*lone* CR (&#13;), 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 → ---
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 &#10; 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.
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.
Assignee: layout → nobody
QA Contact: chrispetersen → layout
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: