Closed Bug 17950 Opened 25 years ago Closed 25 years ago

Inconsistent line termination causes page to render incorrectly

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
All
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sfraser_bugs, Assigned: rickg)

References

(
URL
)

Details

(Whiteboard: [testcase needed]) 

The page at the URL above contains mostly CRLF line termination, but has isolated
LFs in a few places. This page renders fine in 4.5, but renders incorrectly in
apprunner.

Things to bad after the end of the main story (just after the "******** "Search/
Back to top" ********" comment).
Status: NEW → ASSIGNED
The bug appears to be in the parser::comment code.
Here's a reduced test case:
<html>
<body>
<FONT SIZE=1 FACE="Arial, Helvetica">
  Text here!
</FONT>
<!--******** "Search/Back to top" ******** component -->
<IMG SRC="/furniture/rickgerror.gif" WIDTH=328 HEIGHT=1><BR>
<FORM ACTION="/scripts/query.idq" METHOD=GET>
  <INPUT SIZE=30 NAME="CiRestriction" TYPE="TEXT">
  <INPUT VALUE=32 NAME="CiMaxRecordsPerPage" TYPE="HIDDEN">
</FORM>
end of text
</body>
</html>
Actually, the last comment is false. Still searching...
This bug causes almost all the pages at <http://news.bbc.co.uk> to render
incorrectly.
Whiteboard: [testcase needed]
Assignee: rickg → sfraser
Status: ASSIGNED → NEW
Simon -- here's the updated version of CNewLineToken::Consume(); it lives in the
file nsHTMLTokens.cpp. Please apply this change, build and run to see if it
fixes this problem for you. Thanks.


/*
 *  Consume as many cr/lf pairs as you can find.
 *
 *  @update  gess 3/25/98
 *  @param   aChar -- last char consumed from stream
 *  @param   aScanner -- controller of underlying input source
 *  @return  error result
 */
nsresult CNewlineToken::Consume(PRUnichar aChar, nsScanner& aScanner,PRInt32
aMode) {

  mTextValue=kNewLine;  //This is what I THINK we should be doing.

/*******************************************************************

  Here's what the HTML spec says about newlines:

  "A line break is defined to be a carriage return (&#x000D;),
   a line feed (&#x000A;), or a carriage return/line feed pair.
   All line breaks constitute white space."

 *******************************************************************/

  PRUnichar theChar;
  nsresult result=aScanner.Peek(theChar);

  if(NS_OK==result) {
    switch(aChar) {
      case kNewLine:
        if(kCR==theChar) {
          result=aScanner.GetChar(theChar);
        }
        break;
      case kCR:
          //convert CRLF into simple newline
        if(kNewLine==theChar) {
          result=aScanner.GetChar(theChar);
        }
        break;
      default:
        break;
    }
  }
  return result;
}
Target Milestone: M13
I'm setting this to M13 -- Simon, if you can get to this before then, the reset
the milestone date.
I'm not seeing the problem in a current build even before I apply this patch. The
test page above renders reasonably well (if slowly).
Assignee: sfraser → rickg
It renders OK with the patch too, so the patch didn't make any difference in this
case. This bug must have been fixed elsewhere.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking fixed, since the problem no longer occurs.
updated qa contact.
QA Contact: janc → bsharma
Verified on
build: 2001-05-29-20-Trunk
platform: Win NT

The attached url loads ok.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.