If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

REOPENED
Unassigned

Status

()

Core
Layout
P3
normal
REOPENED
15 years ago
8 years ago

People

(Reporter: Vladislav Malyshkin, Unassigned)

Tracking

({testcase})

Trunk
Future
Other
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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.

Comment 1

15 years ago
Created attachment 107698 [details]
reporter's testcase

mozilla linux trunk build 20021126 displays like this:
-----------------------------
NO CR

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


WITH CR

--123--

--345--

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

Parser?

Updated

15 years ago
Keywords: testcase

Comment 2

15 years ago
.
Assignee: block-and-inline → harishd
Component: Layout: Block & Inline → Parser
QA Contact: ian → moied

Comment 3

15 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

Comment 4

15 years ago
--> Sounds like layout.
Assignee: harishd → other
Component: Parser → Layout
QA Contact: moied → ian

Comment 5

15 years ago
I see it on Netscape 7.02 and Mozilla on WinXP platform.
OS: Linux → All
Priority: -- → P3

Updated

15 years ago
Target Milestone: --- → Future

Comment 6

15 years ago

*** This bug has been marked as a duplicate of 98356 ***
Status: NEW → RESOLVED
Last Resolved: 15 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
You need to log in before you can comment on or make changes to this bug.