Closed Bug 273085 Opened 20 years ago Closed 20 years ago

HTML tags displayed as part of text

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ajschult784, Assigned: mrbkap)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(2 files)

testcase
32 bytes, text/html
Details
Fixes the problem
1.52 KB, patch
bryner
: review+
dbaron
: superreview+
Details | Diff | Splinter Review 
I've seen this happening with recent trunk builds, and finally got a working
testcase.  I see this when parsing documents in small chunks (I have a PHP
script that serves the testcase 2 bytes at a time), but I've seen this in
bugzilla bug lists and the given URL (from bug 101013).

This regressed between linux trunk builds 2004112405 and 2004112506, indicating
bug 269853.

I also see a parser hang when loading the full URL slowly (10 bytes at a time)
that regressed at the same time.
Attached file testcase — 
loading this with linux trunk 2004120305 (served up 2 bytes at a time) displays
"</head>".  Note that there is a space after "<head>" and "</head>"
I can see this on windows with bugzilla long bug lists
I can reproduce this (using the method described in comment 1). The problem
appears to be that nsScanner::Peek() is returning NS_OK when it should be
returning kEOF (the returned character is invalid). I'll look at this more tomorrow.
The problem here is that we get a space as the last character in a chunk.
nsScanner::Peek() gives us the space so we call
nsHTMLTokenizer::ConsumeWhitespace(). This calls nsScanner::GetChar() on the and
asks a CWhitespaceToken to consume the text. This starts out by getting the
current posistion and decrementing it, but the decremented position is in
another league (nsScanner::mCountRemaining ends up being 8523 or so) leading to
the problem I mentioned in ocmment 3.
Stealing from bryner (sorry). We were calling SetPosition() with an argument
that was before mCurrentPosition (and in a different buffer), and
nsScannerBufferList::Position::Distance() couldn't cope. This may fix bug
274105 (it points to the same code, and in fact, I'm not sure why we don't
crash here). While I was at it, I fixed a similar (potential) problem with
comment handling.
Assignee: bryner → mrbkap
Status: NEW → ASSIGNED
Attachment #168624 - Flags: superreview?(dbaron)
Attachment #168624 - Flags: review?(bryner)
Attachment #168624 - Flags: review?(bryner) → review+
Attachment #168624 - Flags: superreview?(dbaron) → superreview+
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 274045 has been marked as a duplicate of this bug. ***
Blocks: 274105
Flags: blocking1.8a6?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: