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.
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?
Confirming. The effect is still present in linux nightly 2002122708.
--> Sounds like layout.
I see it on Netscape 7.02 and Mozilla on WinXP platform.
*** This bug has been marked as a duplicate of 98356 ***
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.
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.
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.