Closed Bug 100474 Opened 23 years ago Closed 15 years ago

HTML font tag displayed unparsed

Categories

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

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: dchin, Unassigned)

References

()

Details

(Whiteboard: [fixed by the HTML5 parser])

Attachments

(9 files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 BuildID: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010913 at http://aqdt.fear.net/cgi-bin/ultimatebb.cgi?ubb=forum&f=3 an item in the Date column of the table did not properly have a font tag parsed and executed. it outputted as plain-text. a screenshot can be found here: http://www.nand.net/~dschin/pix/mozillabug.jpg Reproducible: Sometimes Steps to Reproduce: various layout problems on that page, random. Expected Results: that one tag should render as a normal FONT tag. win2k SP2, fully patched.
I cannot repro this bug, but I have definitely seen what you show in the screen shot before, on other sites. Over to Harish since he is generally interested in that stuff...
Assignee: attinasi → harishd
Component: Layout → Parser
Summary: HTML font tag isn't parsed. → HTML font tag displayed unparsed
Marking WFM 2001092208 on Win2k. Reporter: If you can reproduce this on a more recent build, please reopen this bug: http://ftp.mozilla.org/pub/mozilla/nightly/latest/
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
reproduced with latest build on separate machine Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4+) Gecko/20010924 same site, different tag being displayed and not parsed <TD valign="top" bgcolor="#333333"> screenshot 1: http://www.nand.net/~dschin/pix/mozillabug2.png screenshot 2: http://www.nand.net/~dschin/pix/mozillabug3.png these were not on the same refresh. the first was taken, I browsed a bit more, and after a few other links, returned to http://aqdt.fear.net/cgi- bin/ultimatebb.cgi?ubb=forum&f=3 and saw the second screenshot (mozillabug3.png) refreshing fixes it. I cannot find a condition that reproduces this. It seems to happen randomly on my Windows 2000 machine AND on our development XP machine.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Reporter: Can you try this with a fresh profile? You can manage/create profiles with "mozilla.exe -profilemanager".
created new profile per instructions, went to http://aqdt.fear.net/cgi- bin/ultimatebb.cgi and clicked "Just some BS" screenshot here: http://www.nand.net/~dschin/pix/mozillabug4.png still have the same symptoms. this time a </td> is displayed in the first column. please note that despite the error on a cell close tag, the columns are not disturbed, as a missing </td> often does. They are still in alignment. I won't speculate why this is so. taken from Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4+) Gecko/20010924 later tonight or tomorrow I will try a more recent build. lastly, should i continue with the screenshots?
dschin: The screenshots are fine, and I think they help describe the problem. However, that last one (http://www.nand.net/~dschin/pix/mozillabug4.png) seems to be corrupted, as it's not loading for me. When you try a more recent build, be sure to delete your old Mozilla directory before installing the new build. Anyhow, I still can't reproduce this, but I'll mark it as NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 102218 has been marked as a duplicate of this bug. ***
See bug 102218 which was marked as a duplicate. You should be able to reproduce it easily at that site.
I'm not able to reproduce the problem. When I tried the URL mentioned in bug 102218 it asks me for userid & passwd. Could someone please attach a testcase? It is not a good idea to open up a bug based on a dynamic page. At least attach a copy of the problem page and may be we can derive a reduced testcase out of it.
just experienced bug with 0.9.5 on http://www.fear.net/cgi-bin/ultimatebb.cgi? ubb=forum&f=3 all screenshots are now at www.nand.net/~dschin/mozillastuff the most recent example is mozillabug6.png and (mozillabug6.html is the associated HTML file, as requested by harishd@netscape.com again, its not consistant, and I cannot reproduce it at will. however, i do post a lot on that messageboard, and will get it randomly at least once per session. try browsing topics, and hitting "back" to go back to the index screen a few times. also, realize that when i am browsing, i'm a registered user and logged in. (session vars and cookies are both probably utilized. I just registered a test user, "mozillatest" to use. email me for the pw if you do not want to register yourself.
I'm the person who filed bug 102218. In it I wrote you that can email me and I'll send you the user id and password. I also wrote that because of the prolem with view source and pages generated by posts, I can't see if Mozilla is rendering the source incorrectly, or if the source is being mangled before it gets to the renderer. Irregardless, email me at rdebay@iisystems.com and I will send you the user id and password.
Looking at the Palm Beach County web site again with 0.9.5, I can see it exhibits the same behavior that dschin@nand.net is seeing. The anchor tag followed by the anchor text is displayed, and the closing anchor tag is not displayed. It only seems to happen in tables. I used IE to save the source, and used 0.9.5 to view the file. I could not get it to fail. So you must view the site directly. Please email me at rdebay@iisystems.com so Mozilla will work properly with this site.
Mozilla 0.9.5+ Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.5+) Gecko/20011107
choosing View-Source was yielding a blank window, so this was generated by saving the web page via file->save as. again, using build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.5+) Gecko/20011107
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.8
Priority: P2 → P3
Target Milestone: mozilla0.9.8 → mozilla1.0
Mass moving bugs to 1.1
Target Milestone: mozilla1.0 → mozilla1.1
Attached image problem still exists under 0.9.8 (deleted) —
Mozilla 0.9.8 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.8) Gecko/20020204
Attached image screenshot of unparsed HTML bug (deleted) —
The <acronym> tag shouldn't be displayed at all, as demonstrated by other rows in the table. HTML source will be in another attachment coming. URL is, again, from http://www.fear.net/ultimatebb.cgi Mozilla 1.0 Release Candidate 1 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc1) Gecko/20020417 WinXP
Sourcecode from Attachment #81172 [details] . steps to reproduce: still unable to reproduce at will- only occurs at random.
again from http://www.fear.net/cgi-bin/ultimatebb.cgi?ubb=forum&f=3 this time, a < font> tag fails to be parsed. HTML source coming.
Attached file sourcecode to attachment 83464 (RC2) (deleted) —
sourcecode to attachment 83464 [details] (RC2) Mozilla 1.0 Release Candidate 2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0rc2) Gecko/20020510
I've a fix in bug 117441.
[was 1.1alpha]
Target Milestone: mozilla1.1alpha → Future
I'm having the same problem with some server side includes that are not parsed, but displayed! In every other browser i don't se the tags rendered, but in mozilla i get, for example, "<%INCLUDE /folha/mainhighlight.inc%>" outputed as text in the html final rendering. I'm using a nightly build downloaded today (ID: 2003020808)
This is still showing up in Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3b) Gecko/20030202. Is there anyone looking at it?
comment #25 refers to bug 72565 and is irrelevant to this bug.
I am experiencing the same problem for files on my site that have certain truetype fonts, running Build 2004042110 (1.7rc1) on Fedora Core 1 (2188). The problem does not occur with 1.6 on Windows 98, but does occur with 1.6 on Linux. The fonts are SPIonic, SPTiberian, and SPEdessa. The problem can be observed in the following files, all in the directory http://www.constitution.org/sr/ q02.htm q03.htm q04.htm q05.htm q06.htm q07.htm q08.htm q09.htm q13.htm q18.htm q19.htm q20.htm q23.htm q25.htm q26.htm q29.htm q30.htm q31.htm q32.htm q33.htm q35.htm q39.htm q40.htm q41.htm q42.htm q43.htm It should be noted that the fonts have been detected by Mozilla and appear in the list of fonts one can select in Edit | Preferences | Appearance | Fonts. It should also be noted that the same problem appears when using the Gnome browser, as in the Navigator file manager, but it does not appear when using the KDE browser, as in Konqueror, which displays all fonts correctly. It might be useful to examine the source code for each of those browsers to see why one works and the other doesn't.
I should add that I considered the possibility the value of the face attribute in <font face="SPIonic"> ... </font> might be case-sensitive, and experimented with different cases in both the HTML page in in the files themselves. That didn't help.
Assignee: harishd → nobody
Status: ASSIGNED → NEW
QA Contact: chrispetersen → parser
It seems that the HTML5 parser does not have this problem.
Depends on: html5-parsing
Status: NEW → RESOLVED
Closed: 23 years ago15 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by the HTML5 parser]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: