I'm not sure if this is the correct componant. Mozilla appears to be eating and/or emititng various tags (</a> </nobr> <li> <table>), etc. This causes layout problems (as columns are resized, etc). Sometimes this also causes content not to be displayed, depending on what tag is incorrect (eg end of table does not display, etc) Also see the attached screenshot (the results of a bugzilla query to search for a dupe). Slashdot (as an unlogged in user) shows all the slashboxes one under the other, under the stories which are written as black text on a black background (except for the links) Reload fixes the problem, usually, although sometimes teh new page will have a different problem.

Confirming on today's build under Linux.

CC'ing Vidur@netscape.com who made changes to the html parser yesterday. Hope you can find the problem.

I can confirm this one too and I hope it would be fixed soon because it's really annoying bug.

Changing OS to ALL, I see this on a cvs build from yesterday (12/13) on Win98.

Seen with Mozilla 2000121408, Mac OS 9. Platform -> All

this is very bad, seeing it on many sites. must address for beta1.

*** Bug 62951 has been marked as a duplicate of this bug. ***

*** Bug 62944 has been marked as a duplicate of this bug. ***

*** Bug 62994 has been marked as a duplicate of this bug. ***

http://bugzilla.mozilla.org/query.cgi and http://www.mozilla.org/mozorg.html are listed as problem sites in some of the DUPs. Harishd and I are trying to recreate.

I found doing bonsai queries (ie clicking dates from tinderbox) seem to show up </A> problems often.

For some reason, my net connection is very slow today and I'm seeing this much more. What happens if half the tag comes in a different network packet to another - ie the tag is split between buffers? Or am I clutching at straws here? This would explain why bugzilla queries show this problem.

The above testcase contains mostly the markup <b></b>. Lots of it. You should only see the text "alma", and no tags if it works correctly. Mozilla fails even if the file is saved locally. Looks like a block boundary problem. Nominating dogfood, it causes all kinds of suprising problems e.g. with bugzilla.

This seems to fix the last testcase at least, dunno if this is the right thing to do tho but the code I changed looks wrong so it could be, Vidur, what do you think? (Note that this is a diff -w so clean up the indentation if this is checked in) Index: nsScanner.cpp =================================================================== RCS file: /cvsroot/mozilla/htmlparser/src/nsScanner.cpp,v retrieving revision 3.82 diff -u -w -r3.82 nsScanner.cpp --- nsScanner.cpp 2000/12/12 21:57:59 3.82 +++ nsScanner.cpp 2000/12/18 05:15:31 @@ -473,14 +473,13 @@ if(NS_OK == result){ if (aOffset) { - if (mCountRemaining < aOffset) { - result = Eof(); + if (mCountRemaining <= aOffset) { + return kEOF; } - else { + nsReadingIterator<PRUnichar> pos = mCurrentPosition; pos.advance(aOffset); aChar=*pos; - } } else { aChar=*mCurrentPosition; Also, this code in nsHTMLTokenizer.cpp looks odd: default: if(nsCRT::IsAsciiAlpha(aChar)) { // Get the original "<" (we've already seen it with a Peek) aScanner.GetChar(oldChar); result=ConsumeStartTag(aChar,aToken,aScanner,aFlushTokens); } --> else if(kEOF!=aChar) { // We are not dealing with a tag. So, don't consume the original // char and leave the decision to ConsumeText(). result=ConsumeText(aToken,aScanner); } aChar is a PRUnichar (16 bit) and kEOF is a PRUint32 whose value is NS_ERROR_GENERATE_FAILURE(NS_ERROR_MODULE_HTMLPARSER,1000) which is is way larger than 2^16 so the check is always true, could someone clean this up, Harish? I'm surprised the compiler doesn't catch that unecessary check.

*** Bug 63167 has been marked as a duplicate of this bug. ***

*** Bug 63153 has been marked as a duplicate of this bug. ***

A slight variant on Johnny's patch. Thanks to him for tracking this down quickly and Péter Bajusz for a simple test case. Index: src/nsScanner.cpp =================================================================== RCS file: /cvsroot/mozilla/htmlparser/src/nsScanner.cpp,v retrieving revision 3.82 diff -u -r3.82 nsScanner.cpp --- nsScanner.cpp 2000/12/12 21:57:59 3.82 +++ nsScanner.cpp 2000/12/18 18:05:30 @@ -411,9 +411,7 @@ return kEOF; } - if (mCurrentPosition == mEndPosition) { - theError=FillBuffer(); - } + theError=FillBuffer(); if(NS_OK==theError) { if (0==(PRUint32)mSlidingBuffer->Length()) { @@ -473,10 +471,11 @@ if(NS_OK == result){ if (aOffset) { - if (mCountRemaining < aOffset) { + while ((NS_OK == result) && (mCountRemaining <= aOffset)) { result = Eof(); } - else { + + if (NS_OK == result) { nsReadingIterator<PRUnichar> pos = mCurrentPosition; pos.advance(aOffset); aChar=*pos; Index: src/nsHTMLTokenizer.cpp =================================================================== RCS file: /cvsroot/mozilla/htmlparser/src/nsHTMLTokenizer.cpp,v retrieving revision 3.72 diff -u -r3.72 nsHTMLTokenizer.cpp --- nsHTMLTokenizer.cpp 2000/12/12 21:57:54 3.72 +++ nsHTMLTokenizer.cpp 2000/12/18 18:05:30 @@ -539,7 +539,7 @@ aScanner.GetChar(oldChar); result=ConsumeStartTag(aChar,aToken,aScanner,aFlushTokens); } - else if(kEOF!=aChar) { + else { // We are not dealing with a tag. So, don't consume the original // char and leave the decision to ConsumeText(). result=ConsumeText(aToken,aScanner);

Vidur's patch looks good to be r=harishd

Vidur's patch looks good to me r=harishd

Fix checked in on 12/18/2000.

*** Bug 63319 has been marked as a duplicate of this bug. ***

updated qa contact.

Verified on: build: 2001-03-29-09-Mtrunk Platform: Win NT All of the above attached test cases loads fine.

See something similar at www.zdnet.ru mozilla 0.9.2

aw geez...not this bug again...confirming on Win2k pro, 2001062904. I see a <td valign="middle"> right next to the picture of gates at the top of the page (maybe gates cursed us =p)

I'm not seeing the problem ( July 13th trunk build & July 18th branch build ). Visited www.zdnet.ru, http://www.mozilla.org/mozorg.html, and loaded the testcase ( ref. comment 2000-12-17 14:27 ). Marking WFM.

Verifying Linux 2001091121

I still see this bug with Mozilla 0.9.5 at www.zdnet.ru, but it's really rare.