117441 - HTML tag appearing on page

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[basic]

build ID: 2001122703
UA: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+) Gecko/20011227
nightly win32 full installer trunk

also seen with mozilla0.9.7 win32 full installer

The above URL sometimes shows a <tr bgcolor="#D3DEE7" background=""> just above
the "shop" above the "Beauty durch Algen"

steps to repro:
1. goto the URL above.
2. if the HTML tag doesn't appear, reload until it does...

expected result:
never have HTML tag appearing

actual result:
HTML tag appears quite often

Comment 1

[Mauricio Collares [:collares]]

WFM using linux cvs build (20011228).. Even downloading the page @ 0.1KBps, I am
unable to confirm this

Comment 2

[basic]

another way to reproduce this bug is to click on "Bücher" and "Wein & Gourmet"
alternately. I find html tags like <tr bgcolor="#D3DEE7" background=""> and <img
src="img/s.gif" width="5" height="21"> appearing. Maybe this has something to do
with my connection speed and or my using w2k?

Comment 3

[basic]

I'm getting <td background="img/bluewhite.gif"> sometimes.

After I see the bug, if I go back to the previous page and then foward it
disappears.

with mozilla0.9.7 I also used the DOM inspector to take a look and found that
those tags are contain in text nodes.

Comment 4

[basic]

this might be a cache bug (related to bug 113139 ? though I don't see the crash)

Comment 5

[Boris Zbarsky [:bzbarsky]]

There is already a bug on HTML tags appearing in page text...

Comment 6

[Markus Gerstel]

That was bug 62782

Comment 7

[basic]

there is bug 115881 but that is an evang and claims to be caused by ads.
there is bug 62782 but has since been marked wfm though the last comment
mentions that it can still be seen sometimes.

Comment 8

[Markus Hübner]

I see this nearly everyday, but I when reloading this doesn't occur a second 
time. Unfortunately don't know how to reproduce but see this too.
(latest run with build 2002012008 on winxp).

Comment 9

[Moied]

Using build ID 20020207 on win2k and winxp, can't see HTML tag appearing by
visting  above URL also tried to reproduse by clicking on "Bücher" and "Wein &
Gourmet"
alternately Resolving WFM.

Comment 10

[basic]

I'm still seeing the problem in build 2002020603 win32 trunk on win2k
I'll check again with the next nightly I download

Comment 11

[basic]

Attachment: html tag screenshot (build 2002020603)

Comment 12

[basic]

Attachment: no html tag screenshot (build 2002020603)

Comment 13

[basic]

I'm seeing a </tr> on this page:
http://www.world-direct.com/step2/shop.asp

the weird part is that I don't ussually see it unless I load that page by
clicking "shop" in the bar.

Comment 14

[Markus Hübner]

Seeing this for quite a while. Using build 2002030403 on win-xp.
The bug occurs when doing a reload during the page reloads ...
http://www.world-direct.com/step2/shop.asp?id=4&lid=&menu=sh_hifi

So incremental reflow might be related to this problem.

Comment 15

[Markus Hübner]

Attachment: Screenshot of page with tag rendered

Comment 16

[Markus Gerstel]

I've seen it on a few other occasions (maybe 10) and noticed that the appearing
tags are all table-related. There is one <img> tag mentioned in this bug, but
I've never seen one of these.

Comment 17

[Markus Hübner]

With build 2002030508 for example the page
http://www.world-direct.com/step2/shop.asp?id=4&lid=&menu=sh_hifi
is broken for me nearly every third time.

Comment 18

[Dimitrios]

When I save the page locally (using "Save As Complete"), it shows some "b"
characters in the same region you see the <td> tags. After removing the 
<meta http-equiv="Content-Type" content="text/html; charset=UTF-16">
line, no problem.
Not sure but it might be a related to the known issue (bug id?) of trying to
read  external ascii css as utf, because of the unicode charset definition in
the html page.

Comment 19

[basic]

charset/parser issues?

Comment 20

[Ole Kasper Olsen]

Attachment: screenshot from 3DR UBB

Comment 21

[Markus Gerstel]

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

Comment 22

[Charles Capps]

Note that a UBB forumdisplay page (a list of topics) will display the problem
noted in the screencap.... if the calls to document.writeln() are removed from
the table, the error will no longer occur. 

This occurs regardless of the UBB template set used (including an old
non-validating HTML 4 set and a validating XHTML 1.0 Transitional set), and
seems directly related to the document.writeln() call...

Comment 23

[Christopher Hoess (gone)]

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

Comment 24

[harishd]

I see the problem very often in http://trinity.westhost.com/tomb/revelation/

Comment 25

[harishd]

The problem is probably due to an embedded null character.

That is, say the input buffer looked something like
<html><body><\0a href="foo">foo</a> then when we encounter the null character,
right after '<', we immediately assume that the '<' is not a part of a start tag
and start consuming it ( '<' ) as text.

Comment 26

[harishd]

It turns out that my guess is right. I did see an embedded null character right
after '<'. Need to figure out how the null character got in there. I've
confirmed that it's not from the server.

Comment 27

[Christopher Hoess (gone)]

Maybe this is just a consmetic fix, but could the Scanner be modified to
silently ignore null characters and get/peek at the next character, instead?

Comment 28

[harishd]

>Could the Scanner be modified to silently ignore null characters and get/peek
at >the next character, instead?

That would be a temp fix and that's what I'm going for :). We can later figure
out how the null got in there.

Comment 29

[/\/\arcio Galli]

I created two testcases based in the example that Harish sent. 

The first one is exactly the same page from the trinity site and demonstrates
the same problem. 

http://taboca.com/tests/tomb8.html

The second one do not show the problem based in my tests. 
http://taboca.com/tests/tomb8a.html

The only difference between the first and the second is the addition of one
character. I was  adding and removing one character in areas like the title or
html comments and looks consistent. 

Comment 30

[scottputterman]

getting this on the rtm radar.

Comment 31

[Frank Tang]

do we really know what happen here?
I see no problme with the two cases. 

Comment 32

[harishd]

Frank: Read comment #25.

Comment 33

[harishd]

Attachment: patch v1.0

Making sure to update mCountRemaining when data get inserted into the scanner
buffer.

Comment 34

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Comment on attachment 83446 [details] [diff] [review]
patch v1.0

r=heikki

Comment 35

[Johnny Stenback (:jst)]

Comment on attachment 83446 [details] [diff] [review]
patch v1.0

sr=jst

Comment 36

[Jaime Rodriguez, Jr.]

moied - can you verify that the patch fixes the problem, and does not cause any
regressions?

This might be a good one to take now, but absorbing this risk is up to Drivers
for RC3.

Comment 37

[harishd]

Fix landed ( 05/15 ) on the trunk.

Comment 38

[scottputterman]

moied, can you verify this on the trunk before it gets considered for rtm.

Comment 39

[/\/\arcio Galli]

Tested this one with today's Mozilla trunk in Win98 and really works! now!!
great!! The tomb/revelation web site was the only consistent case, now with many
many reloads, cache-clean reloads I could not see the problem! fixed and ready
based in my tests. 

Comment 40

[Moied]

Having no trouble with this patch, tested several potential sites with this
problem  and testcases with Mozilla trunk 20020517 on winxp. 

Comment 41

[Charles Capps]

I also see this fixed in 2002051708 on Win2k... however it's also quite
unusable, so perhaps that's not the best benchmark to judge by...

Comment 42

[Jaime Rodriguez, Jr.]

Has this been fixed and verified on the trunk. IF yes, then this should be
marked Verified.

Comment 43

[scottputterman]

adding adt1.0.0+ for checkin to the branch.  Please get drivers approval.

Comment 44

[Dawn Endico]

Comment on attachment 83446 [details] [diff] [review]
patch v1.0

a=chofmann,brendan
please check in to 1.0 branch asap to get this in rc3.

Comment 45

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 46

[Randell Jesup [:jesup] (needinfo me)]

I see this fix was checked into branch and trunk; so marking.  

Comment 47

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 48

[Moied]

Marking verified with branch build ID 20020523 on winxp, adding a KW:Verified1.0.0