Closed Bug 117441 Opened 23 years ago Closed 23 years ago

HTML tag appearing on page

Categories

(Core :: DOM: HTML Parser, defect)

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

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: basic, Assigned: harishd)

References

(
URL
)

Details

(Keywords: regression, topembed+, Whiteboard: DUPEME [adt1 rtm][fixed on the trunk 05/15] [Needs ADT+ & a=])

Attachments

(5 files)

html tag screenshot (build 2002020603)
(deleted), image/png
Details
no html tag screenshot (build 2002020603)
(deleted), image/png
Details
Screenshot of page with tag rendered
(deleted), image/gif
Details
screenshot from 3DR UBB
(deleted), image/png
Details
patch v1.0
(deleted), patch
hjtoi-bugzilla
: review+
jst
: superreview+
endico
: approval+
Details | Diff | Splinter Review
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
WFM using linux cvs build (20011228).. Even downloading the page @ 0.1KBps, I am unable to confirm this
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?
Keywords: qawanted
Summary: html tag appearing on page → HTML tag appearing on page
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.
this might be a cache bug (related to bug 113139 ? though I don't see the crash)
There is already a bug on HTML tags appearing in page text...
Whiteboard: DUPEME
That was bug 62782
Whiteboard: DUPEME
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.
Whiteboard: DUPEME
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).
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.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Keywords: qawanted
Resolution: --- → WORKSFORME
I'm still seeing the problem in build 2002020603 win32 trunk on win2k I'll check again with the next nightly I download
Attached image html tag screenshot (build 2002020603) (deleted) —
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.
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.
Severity: normal → major
Status: RESOLVED → UNCONFIRMED
Keywords: mozilla1.0
Resolution: WORKSFORME → ---
Attached image Screenshot of page with tag rendered (deleted) —
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
Keywords: regression
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.
charset/parser issues?
Attached image screenshot from 3DR UBB (deleted) —
*** Bug 135899 has been marked as a duplicate of this bug. ***
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...
*** Bug 137566 has been marked as a duplicate of this bug. ***
Keywords: helpwanted
I see the problem very often in http://trinity.westhost.com/tomb/revelation/
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.
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.
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?
>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.
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.
Keywords: topembed
Whiteboard: DUPEME → DUPEME [adt1]
Whiteboard: DUPEME [adt1] → DUPEME
Whiteboard: DUPEME → DUPEME [adt1]
getting this on the rtm radar.
Keywords: nsbeta1+
Whiteboard: DUPEME [adt1] → DUPEME [adt1 rtm]
Target Milestone: --- → mozilla1.0
do we really know what happen here? I see no problme with the two cases.
Frank: Read comment #25.
Attached patch patch v1.0 (deleted) — — Splinter Review
Making sure to update mCountRemaining when data get inserted into the scanner buffer.
Whiteboard: DUPEME [adt1 rtm] → DUPEME [adt1 rtm][fix in hand]
Keywords: topembed → topembed+
Comment on attachment 83446 [details] [diff] [review] patch v1.0 sr=jst
Attachment #83446 - Flags: superreview+
Blocks: 143047
Keywords: approval
Whiteboard: DUPEME [adt1 rtm][fix in hand] → DUPEME [adt1 rtm][fix in hand] [Needs ADT+ & a=]
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.
Keywords: adt1.0.0
Fix landed ( 05/15 ) on the trunk.
Keywords: qawanted
Whiteboard: DUPEME [adt1 rtm][fix in hand] [Needs ADT+ & a=] → DUPEME [adt1 rtm][fixed on the trunk 05/15] [Needs ADT+ & a=]
moied, can you verify this on the trunk before it gets considered for rtm.
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.
Having no trouble with this patch, tested several potential sites with this problem and testcases with Mozilla trunk 20020517 on winxp.
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...
Has this been fixed and verified on the trunk. IF yes, then this should be marked Verified.
adding adt1.0.0+ for checkin to the branch. Please get drivers approval.
Keywords: adt1.0.0 → adt1.0.0+
Attachment #83446 - Flags: approval+
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.
*** Bug 115881 has been marked as a duplicate of this bug. ***
I see this fix was checked into branch and trunk; so marking.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Keywords: helpwanted, qawanted → fixed1.0.0
Resolution: --- → FIXED
*** Bug 118380 has been marked as a duplicate of this bug. ***
Marking verified with branch build ID 20020523 on winxp, adding a KW:Verified1.0.0
Status: RESOLVED → VERIFIED
Keywords: verified1.0.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: