377056 - very deeply nested <font> tags are ignored

Status: RESOLVED DUPLICATE of bug 256180

(Core :: DOM: HTML Parser, defect)

Description

[Joseph Piché]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20061201 Firefox/2.0.0.3 (Ubuntu-feisty)

When there are more than 156 font tags, each with individual colors set by using CSS, embeded within each other, the font tags after the 156th do not render the set color style.

short example: <font color=111111>something<font color=222222>something ... 
or <font style="color:#111">something<font style="color:#222">something ...
... repeated many times, the tags after the 156th do not render the proper colors.

Reproducible: Always

Steps to Reproduce:
1. load the html.
2.
3.
Actual Results:  
Rendered incorrectly.

Expected Results:  
Every font tag to be rendered correctly.

Comment 1

[Joseph Piché]

Attachment: This is a testcase showing the bug.

Comment 2

[Phil Ringnalda (:philor)]

That's the expected result of bug 58917 and bug 18480, but I'm not sure whether
bug 256180 is the one true "find some way to tolerate infinite nesting" bug or
not.

Comment 3

[Jesse Ruderman]

Don't do that?  (Close the font tags.)

Comment 4

[Joseph Piché]

LOL. This is not something that I practice regularly (or at all). This bug was something that I ran across accidentally, and figured that since Konqueror and IE7 both render it correctly, that I would file the bug.

Comment 5

[Joseph Piché]

I have tested this on a few other machines and am therefore changing the _hardware_ and _version_ of this bug, since it renders the same regardless of the OS and arch.

Comment 6

[Joseph Piché]

This bug may be a duplicate of bug 256180. Both bugs are a result of MAX_REFLOW_DEPTH in parser/htmlparser/public/nsIHTMLContentSink.h being set to 200 (75 on classic macs). I believe this hard coded limit is a bad idea, since it limits what the user can render in the browser. I understand that not having a limit might cause a browser crash or even a buffer overflow, but there has to be another way to fix this bug.