[FIX] No rendering after tag nesting/TAGLVL has been exceeded

RESOLVED FIXED

Status

()

Core
HTML: Parser
P3
major
RESOLVED FIXED
18 years ago
7 years ago

People

(Reporter: Andre Ulli, Assigned: mats)

Tracking

(Blocks: 1 bug, {compat, testcase})

Trunk
compat, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [evil, no </font>, many <font>] [See comment 110], URL)

Attachments

(9 attachments, 2 obsolete attachments)

(Reporter)

Description

18 years ago
This site gets not fully displayed. Maybe this is caused by incorrect HTML code.

Comment 1

18 years ago
over to layout. note, bug 18480 was about a _Crash_ on this page.  no longer
crashing but page fails to lay out completely
Assignee: asa → clayton
Status: UNCONFIRMED → NEW
Component: Browser-General → Layout
Ever confirmed: true
QA Contact: doronr → petersen

Comment 2

18 years ago
This happens on windows 2000 11/01-04 w32 talkback.

basically it's <font><font><font><font><font>...
I don't think there is a </font> anywhere. Nope. Not one.

We'll get someone to do a perl regexp or something to do some magic counting. I 
suspect a magic number for depth was reached. sending to parser.
Assignee: clayton → harishd
Component: Layout → Parser
OS: Linux → All
QA Contact: petersen → janc
Whiteboard: [evil, no </font>, many <font>]

Comment 3

18 years ago
Rickg, is this related to the stack overflow problem??
Assignee: harishd → rickg

Comment 4

18 years ago
here's a simple thoughtcase: <font color=blue>a<p>b<font color=green>c<font 
color=yellow>d<font color=orange>e</p>f
If it isn't too expensive i think that the parser might consider this broken 
algorithm when you encounter a second font tag in the same block (p) with the 
same attributes set (color) search for the first instance of '</', based on 
what it finds it would then arrange some sort of collapsing mechanism.  In this 
case it finds the </p>, while it's encountering <font> tags that simply 
override the previous tag, it can rest assured knowing that they imply 
</font><font>.
so the parser using my broken algorithm thinks about my testcase like this 
instead:
<font color=blue>a<p>b<font color=green>c</font><font 
color=yellow>d</font><font color=orange>e</font></p>f

Comment 5

18 years ago
updated qa contact.
QA Contact: janc → bsharma

Comment 6

17 years ago
*** Bug 76457 has been marked as a duplicate of this bug. ***

Comment 7

17 years ago
bug 76457 has a nice testcase which does the counting for you.
From my comments in bug 76457:

This limitation of the number of levels of nesting is by design as a workaround
to a serious crash bug (bug 18480).  Basically, a large number of nested tags
means a large number of recursive function calls in the way we do things now and
we end up blowing the runtime stack.

This is not a parser issue -- it's a content model issue. The parser parses
arbitrary levels of nesting fine.

So if the page does not have <p> or </p> or whatever tags there is no way for
the parser to know whether <font><font> really means <font></font><font>

Especially in cases like <font size="7"><font color="red"> ....
*** Bug 60731 has been marked as a duplicate of this bug. ***
See bug 49678.  This sort of problem (too many nested tags) was orignially a 
crasher, but was fixed by that bug.  Currently, we just stop rendering when we 
hit the limit of tag nesting.  Whether or not we want to do something more 
elegant when we hit the limit is an open question-maybe this should just be 
WONTFIX/Evangelize.  Changing summary to reflect situation...
Summary: Site gets not fully displayed → No rendering after tag nesting has been exceeded

Updated

17 years ago
QA Contact: bsharma → moied
Keywords: compat
->harishd
Assignee: rickg → harishd

Comment 12

16 years ago
This needs to be fixed at the CSSFrameConstructor level. It's a hard problem and
I don't think this will get fixed anytime in the near future. Giving bug to
layout for futher assessment.
Assignee: harishd → attinasi
Component: Parser → Layout
QA Contact: moied → petersen

Updated

16 years ago
Target Milestone: --- → Future
*** Bug 145168 has been marked as a duplicate of this bug. ***
*** Bug 156274 has been marked as a duplicate of this bug. ***
For me this fails even on correct HTML that has just too many tags.

The guy who designs pages with DreamWeaver told me it works with NS4 and IE-Win,
it worked for me with IE-mac. The html was ugly but correct.
 
Any HTML document is finite so it should fit into browser memory somehow.
Especially if it has no more tha several hundred KiB.

This definitely is a flaw in Mozilla. Not evangelism bug.
> For me this fails even on correct HTML that has just too many tags.

There is no way to differentiate this from incorrect HTML unless you actually
process all of it.

> Any HTML document is finite so it should fit into browser memory somehow.

I'm not convinced this statement is true (certainly not if scripts are
involved).  Further, it's not the _browser_ memory here but the stack memory
that the OS is willing to give to programs.  This latter is _much_ smaller.

The solution, of course, is to move to a non-recursive algorithm that will not
have as deep a call-stack....

> This definitely is a flaw in Mozilla. Not evangelism bug.

Nobody said it's an evangelism bug.  We all agree it's a flaw.  Possibly one
that is not worth completely rewriting the whole chunk of code involved for, but
a flaw.
*** Bug 156767 has been marked as a duplicate of this bug. ***
*** Bug 156798 has been marked as a duplicate of this bug. ***

Comment 19

16 years ago
I've run into something similar, it shows up as seemingly random missing text
and links. It appears that large numbers of nested <I> and <B> tags along with
the <FONT> tag, droppings that were apparently produced by a broken editor, will
cause the same effect. But <I> and <B> tags alone will also trigger the bug. See
link to example in the wild and testcases at http://www.mtd.com/mozilla-tests.html

BTW, it appears to break exactly the same way on both Windows and Mac 9.x
builds; the amount of system resources seems to have no effect on where and how
it breaks. There is some hard limit involved here.

I'll second the 'evil' status - this is a bug that might quietly leave out parts
of a page, with no obvious evidence of an error. I'd guess that editors that
leave hundreds of garbage tags laying around like this will seriously challenge
the assumption that nested tags can be parsed recursively.
*** Bug 162254 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 21

16 years ago
*** Bug 164223 has been marked as a duplicate of this bug. ***
*** Bug 146940 has been marked as a duplicate of this bug. ***
*** Bug 165688 has been marked as a duplicate of this bug. ***

Comment 24

16 years ago
*** Bug 169744 has been marked as a duplicate of this bug. ***
*** Bug 142786 has been marked as a duplicate of this bug. ***

Comment 26

16 years ago
With all those duplicates already reported, it might be a good idea to fix it?

This is one of the things that is keeping me from using Mozilla as my daily 
browser.
Yes, it's a good idea to fix it.  Feel free to do so.  The fix involved
completely rearchitecting reflow.
Keywords: helpwanted

Comment 28

16 years ago
Hmm... okay, didn't realise that.  Would it be possible to generate an alert or 
something?

Comment 29

16 years ago
*** Bug 172405 has been marked as a duplicate of this bug. ***

Comment 30

16 years ago
Poster of - Bug 172405:

I wouldn't put such a light attitude on fixing this bug, as Kayjey said :

"With all those duplicates already reported, it might be a good idea to fix it?

This is one of the things that is keeping me from using Mozilla as my daily 
browser."

Why use mozilla if it can't display 100% of the web pages out there, when
explorer can?  I Hate Internet Explorer, and will still use mozilla anyways- But
people out there are still going to have that attitude.

Anyways, I've fixed my php scripts and the page now loads, thanks for the tip. 
But that still didn't fix the bug in mozilla.
well, iexplore can _not_ display 100% of the pages on the web; because it has
severe CSS and XML deficiencies.

Comment 32

16 years ago
"well, iexplore can _not_ display 100% of the pages on the web; because it has
severe CSS and XML deficiencies."

Please don't take offense by any means to what I was saying!  I was not ripping
on mozilla (or you at that) _At_ALL_.  I was simply stating that this could
possibly turn people away.  I understand that IE has those deficiencies. 
Unfortunatly I have not encountered any of those sites that IE could not
display, but I have for mozilla (probably because they used some microsoft
specific extension to the standards or something).  I should restate what I said
about 100% of the web pages, to "100% of html only web pages, no javascript, Xml
or CSS".  I'm just saying it looks bad for the browser.  Web designers should
make sure they're stuff is well formed, but you can't control all of them.  (I
changed my stuff, but the next 100 guys might not).  I just don't want to see IE
have something like as trivial (seemingly trivial although from what I hear it
is not) like this on mozilla when mozilla kicks IE's ass in so many other areas.

I didn't mean to turn this bug post into a debate.  Sorry if you took offense by
my previous posts...
*** Bug 176569 has been marked as a duplicate of this bug. ***
*** Bug 177065 has been marked as a duplicate of this bug. ***
*** Bug 178453 has been marked as a duplicate of this bug. ***

Comment 36

16 years ago
*** Bug 179515 has been marked as a duplicate of this bug. ***
*** Bug 183820 has been marked as a duplicate of this bug. ***

Comment 38

16 years ago
*** Bug 184759 has been marked as a duplicate of this bug. ***

Comment 39

16 years ago
*** Bug 186232 has been marked as a duplicate of this bug. ***

Comment 40

16 years ago
Might it be possible to avoid the stack overflow problem by using a depth-first
queue search instead of straight recursion?

essentially, keep a stack of structures detailing the node to visit next, along
with any context necessary to render the node (that it would otherwise have got
from being called from its parent), and then just pop the first node off the
stack, deal with it, and push any of its children onto the stack. Thus the stack
of structures grows, rather than the thread's call stack.

Comment 41

16 years ago
*** Bug 186458 has been marked as a duplicate of this bug. ***

Comment 42

16 years ago
Reassigning to other@layout.bugs
Assignee: attinasi → other
Target Milestone: Future → ---
I just ran into this issue on a framed web page.  On this page, the table
should have two images (a red "Seating Chart" and a blue "Cars Racing")
in the second (right-hand) column of the second row.  The next two rows
should each have a blue "Cars Racing" image in each of the cells in the
second (right-hand) column.

  http://www.trackenterprises.com/2/races/sanctions/woosched.htm

Tested using Mozilla 1.2.1 on Windows 98.

  Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

Renders properly in MSIE 5.50.4807.2300 (SP2; Q316059; Q321232;
q313829; Q323759; Q324929) under Windows 98.

I've created a couple of test cases from the above page (one as
HTML 4.01 Transitional and one as XHTML 1.0 Transitional) that I
will attach to this bug for testing.  Note that the HTML 4.01
Transitional test case does NOT validate with the W3C HTML
Validator (http://validator.w3.org/).  It contains the following
error message (repeated a number of times):

  number of open elements exceeds TAGLVL (100)

Apparently HTML 4.01 Transitional defines the maximum recursion
level for tags to 100.  (That doesn't stop brain-damaged HTML
editors like Front Page from creating such documents, though.)

XHTML 1.0 Transitional apparently has no such limit because it
validates as correct.

I was going to throw in my own US$0.02 about the rendering
algorithm here, but I haven't even glanced at the code and
comment #40 covers what I was going to say anyway.
Created attachment 110220 [details]
HTML 4.01 Transitional Test Case

Test case that validates (with the exception of the TAGLVL 100
violation) as HTML 4.01 Transitional.  Both tables should have
two links:  "One" and "Two".  The left table is missing the
"One" link because of too many nested HTML tags (mostly FONT
tags and with some B tags thrown in).
Created attachment 110221 [details]
XHTML 1.0 Transitional Test Case

Test case that validates as XHTML 1.0 Transitional.  Both tables
should have two links:	"One" and "Two".  The left table is
missing the "One" link because of too many nested HTML tags
(mostly FONT tags and with some B tags thrown in).
I really didn't feel like getting any real work done today, so I
decided to create a torture test for Mozilla using a Perl script to
create a valid XHTML 1.0 Transitional document that had nested FONT
tags of arbitrary length.  (I will attach it shortly.)

Mozilla had NO PROBLEMS rendering a document with 1000 nested FONT
tags.  In fact, Mozilla had no problem rendering a document with
10000 nested identical FONT tags.  (Actually, the last line of the
paragraph with the numbers had a line spacing issue, but that's for
another bug.)

The only difference between this generated file and the test cases
I posted is that the FONT tags aren't all on a single line, and they
each have printable text within them.  I will try to experiment with
the Perl script more to see if I can generate a file that exhibits
the incorrect behavior.
Created attachment 110240 [details]
torture.pl

Perl script to generate a well-formed XHTML 1.0 Transitional
document with N levels of FONT tag nesting.  Usage:

  ./torture.pl N > tortureN.html
Created attachment 110241 [details]
torture1000.html - 1000 nested FONT tags

torture1000.html -- a well-formed XHTML 1.0 Transitional document
with 1000 nested FONT tags (with printable content for each FONT
tag).  Renders properly in Mozilla 1.2.1:

  Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20021106
Created attachment 110242 [details]
XHTML 1.0 Transitional Test Case #2 - No Tables

I took Attachment #110221 [details] and removed all table tags (and the
right-hand table cell), leaving only the problematic HTML.

It now all renders fine in Mozilla 1.2.1.  There's something
strange going on when all of these extra FONT tags appear
inside table tags.
Created attachment 110243 [details]
torture1000-table.html - 1000 nested FONT tags in a TABLE

Ah HA!	Nested FONT tags inside a TABLE will only render up to 193
levels deep.  I have no idea why.

Note that enclosing the same nested FONT tags in DIV or BLOCKQUOTE
tags has no ill effects as all of the numbers (1 to 1000) will
render properly.

It would appear, then, that the code that handles rendering inside
tables is the issue.  Unfortunately, I have no idea how that code
even works.  :)  I hope my torture testing has helped, though.
Added "in tables" to bug summary to denote actual behavior of bug.

N.B. In Comment #48 and Comment #49, I meant Mozilla 1.1, not 1.2.1.
     However, in both cases, Mozilla 1.2.1 on Win 98 behaved the
     same as Mozilla 1.1 on Red Hat 6.2 Linux. Sorry for any confusion.
Summary: No rendering after tag nesting has been exceeded → No rendering after tag nesting has been exceeded in tables
-> layout:tables per comment 50
Component: Layout → Layout: Tables

Comment 53

16 years ago
Created attachment 110279 [details]
content + frame dump

Comment 54

16 years ago
Inline(font)(1)@027AB768 next=027E2174 {315,0,315,195} [state=00000004]
[content=022AFCC0] [sc=027AB710]<                                              
                                                                               
                                                                               
                                                                               
                                                                               
                                                     Text(0)@027AB7D4[0,4,T] 
next=027AB870 {0,0,315,195} [state=50000024] sc=027AB7A0<                      
                                                                               
                                                                               
                                                                               
                                                                               
                       "193\n">
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
                    Inline(font)(1)@027AB870 next=027AB920 {315,150,0,0}
[state=00000804] [content=022AFB80] [sc=027AB818]<                             
                                                                               
                                                                               
                                                                               
                                                                               
                                                                       
Text(0)@027AB8DC[0,0,F]  {0,0,0,0} [state=00000426] sc=027AB8A8<               
                                                                               
                                                                               
                                                                               
                                                                               
                                                                               
       "">
>

The frame dump shows that the frame construction is as deep as necessary but the
text nodes are empty
-> reassign bug to default owner and QA contact for layout:tables per
   comment 52
Assignee: other → table
QA Contact: petersen → amar

Comment 56

16 years ago
tossing this bug around is totally pointless.
Assignee: table → harishd
Component: Layout: Tables → Parser
QA Contact: amar → moied

Comment 57

16 years ago
Strange, as http://bugzilla.mozilla.org/attachment.cgi?id=31297&action=view 
used to render not good.  I first discovered the problem in this dynamically 
generated page and it was not inside a table.  Somebody might have sneaked in 
an partially fixed it?

Comment 58

16 years ago
*** Bug 188631 has been marked as a duplicate of this bug. ***

Comment 59

16 years ago
*** Bug 187331 has been marked as a duplicate of this bug. ***

Comment 60

16 years ago
*** Bug 190552 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 121541 has been marked as a duplicate of this bug. ***
*** Bug 150648 has been marked as a duplicate of this bug. ***
This happens outside tables too if the nesting depth is deep enough.
Summary: No rendering after tag nesting has been exceeded in tables → No rendering after tag nesting has been exceeded

Comment 64

15 years ago
*** Bug 203632 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 65

15 years ago
*** Bug 210634 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 66

15 years ago
Marking Major since missing content without telling the user is a major bug.

I have a patch that should fix most of these problems though...
The idea is to detect this situation by looking at the stack (when it becomes
large) and see if it's mostly made up of font,b,i,em... and similar tags.
If so, I just ignore the new start tag *if it is of that type* until the
situation clears up, thus ignoring style rather than content.
Severity: normal → major
Keywords: helpwanted
Hardware: PC → All
Summary: No rendering after tag nesting has been exceeded → [FIX] No rendering after tag nesting has been exceeded
Whiteboard: [evil, no </font>, many <font>] → [evil, no </font>, many <font>] [patch]
Target Milestone: Future → ---
(Assignee)

Comment 67

15 years ago
Created attachment 126503 [details] [diff] [review]
Patch rev. 1

To be more exact, what I'm ignoring is (kFontStyle|kPhrase) which is, 
kFontStyle //  TT, I, B, U, S, STRIKE, BIG, SMALL, BLINK
kPhrase //  EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, ACRONYM

when the stack size is larger than 75% of MAX_REFLOW_DEPTH and the stack at
that point consists of more than 50% of such containers...
(Assignee)

Comment 68

15 years ago
Comment on attachment 126503 [details] [diff] [review]
Patch rev. 1

I'm also removing "theLineNumber" since it's not used and causes a compiler
warning...
Attachment #126503 - Flags: review?(harishd)
(Assignee)

Comment 70

15 years ago
Created attachment 126506 [details]
Snapshot with Patch rev. 1 applied

Just an example to illustrate, http://www.rmis.rmfamily.com/sites/reguldol.php
after the patch.  All content is rendered, all links are working, but as you
can see the text is not styled correctly after a certain point in the page.

Comment 71

15 years ago
>Marking Major since missing content without telling the user is a major bug.

I don't think we discard the content. We prevent the nesting problem by auto
closing start tags once the nesting limit is reached. Mats, could you please
double check? Thanks.
Keywords: testcase
(Assignee)

Comment 72

15 years ago
Yes, bad choice of words on my part.  For the "end user" the net effect is
the same though - the content is not rendered. Here's the current workaround:

  if (stackDepth > MAX_REFLOW_DEPTH) {
    if (nsHTMLElement::IsContainer(aTag) &&
        !gHTMLElements[aTag].HasSpecialProperty(kHandleStrayTag)) {
      // Ref. bug 98261,49678,55095,55980
      // Instead of throwing away the current tag close it's parent
      // such that the stack level does not go beyond the max_reflow_depth.
      // This would allow leaf tags, that follow the current tag, to find
      // the correct node. 
      while (stackDepth != MAX_REFLOW_DEPTH && NS_SUCCEEDED(result)) {
        result = CloseContainersTo(mBodyContext->Last(),PR_FALSE);
        --stackDepth;
      }
    }        
  }


This comes right after my addition so it still covers the cases my patch
doesn't.  All of the real-world pages where I've seen this bug though
are font/b/i/em and such that are missing end tags.
*** Bug 212893 has been marked as a duplicate of this bug. ***

Comment 74

15 years ago
one more example: http://www.surferos.net/contenido/escuelas/default.asp
3 columns are quickly rendered, before a list of links starts in the mid of the
third column. Rendering of this list is about half a minute delayed, and only
200 of 340 links are shown, here one example, angular brackets replaced by round
ones:
(font face="Verdana, sans-serif" size="1" color="#0066CC")(a
href="/breve.asp?id=342")
(font face="Verdana, sans-serif" size="1" color="#0066CC")(li)Aplazado el
Ballantines por falta de olas</font)(/a)

That font string is identical for all 340 links, and all are missing a </font> tag.

found it in Mozillazine <a
href="http://forums.mozillazine.org/viewtopic.php?p=118088">Web page causes
Mozilla to hang for half minute</a>

Comment 75

15 years ago
*** Bug 211210 has been marked as a duplicate of this bug. ***

Comment 76

15 years ago
tweaking summary to include the validator error "number of open elements exceeds
TAGVL (100)", see comment 43.
Keywords: testcase
Summary: [FIX] No rendering after tag nesting has been exceeded → [FIX] No rendering after tag nesting/TAGVL has been exceeded
(Assignee)

Comment 77

15 years ago
*** Bug 215424 has been marked as a duplicate of this bug. ***

Comment 78

15 years ago
*** Bug 218727 has been marked as a duplicate of this bug. ***
We could also probably increase MAX_REFLOW_DEPTH a good bit if we allocate
nsHTMLReflowState, nsBlockReflowState, and nsTableReflowState using the pres
shell's stack arena instead of using the stack.  (It might be somewhat tricky to
figure out how much, though.)

Comment 80

15 years ago
I've got a similar problem with these pages:
http://home.autocom.pl/mmag/blog/galeria.htm
http://grisha.blog.pl/komentarze/index.php?nid=4554017

The strangest thing is that when I first load a page, it displays correctly, and
when I press "reload" - then it loads cropped.

(using 2003091704 build)

PS. It also looks like a malformed html.
(Assignee)

Comment 81

15 years ago
*** Bug 224838 has been marked as a duplicate of this bug. ***
*** Bug 226344 has been marked as a duplicate of this bug. ***
*** Bug 233881 has been marked as a duplicate of this bug. ***
*** Bug 233885 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 85

15 years ago
*** Bug 235597 has been marked as a duplicate of this bug. ***

Comment 86

15 years ago
The mistake was:

First I have had the HTML- / PHP-Code in this way:

        while ($db->next_record())
        {
                $xsickness = $db->f("sickness");
                $xremedy = $db->f("remedy");
                $x_usage = $db->f("_usage");
                $xnote = $db->f("note");
                $xwherefrom = $db->f("wherefrom");

                print ("<font color=black>");
                print ("<table border=0 width=100%><trbgcolor=#EAE6B7>");
                print ("<td width=20%>$xsickness</td>");
                print ("<td width=20%>$xremedy</td>");
                print ("<td width=20%>$xnote</td>");
                print ("<td width=20%>$x_usage</td>");
                print ("<td width=20%>$xwherefrom</td>");
                print ("</font></tr></table>");
        }


The Error is in the last line (I have written first </font> and than </tr></table>).

I changed the line to:

print ("</tr></table></font>");

And now the page will be shown correctly !!!
*** Bug 76622 has been marked as a duplicate of this bug. ***

Comment 88

14 years ago
*** Bug 251043 has been marked as a duplicate of this bug. ***

Comment 89

14 years ago
Can someone update the patch?  It's probably bitrotted a bit after a year.
(Assignee)

Comment 90

14 years ago
*** Bug 255673 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 91

14 years ago
Taking bug...
Assignee: harishd → mats.palmgren
Status: ASSIGNED → NEW
(Assignee)

Updated

14 years ago
Attachment #126503 - Attachment is obsolete: true
Attachment #126503 - Flags: review?(harishd)
(Assignee)

Comment 92

14 years ago
Created attachment 156541 [details] [diff] [review]
Patch rev. 2

When reaching deep stacks levels start ignoring start tags for certain classes
of elements.  This makes us lose (residual) style at deep levels but that is
preferable to not seeing the content at all.  I checked all testcases and most
of the URLs on the dupes and could not find any missing content (and the loss
of style was hardly noticable).
(Assignee)

Updated

14 years ago
Attachment #156541 - Flags: review?(bzbarsky)
Mats, I'm not going to be able to look at this (or anything else) for at least a
week.

That said, is there a reasonable way to just stop opening residual style stuff
but not "real" tags when the nesting gets too deep?  If so, would that be
preferable?
*** Bug 256230 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 95

14 years ago
(In reply to comment #93)
> That said, is there a reasonable way to just stop opening residual style stuff
> but not "real" tags when the nesting gets too deep?  If so, would that be
> preferable?

That is essentially what the patch does. It ignores the following tags:
  kFontStyle = FONT, TT, I, B, U, S, STRIKE, BIG, SMALL, BLINK
  kPhrase = EM, STRONG, DFN, CODE, SAMP, KBD, VAR, CITE, ABBR, ACRONYM
when the stack depth is 75% of MAX_REFLOW_DEPTH and 50% of that consists
of the above elements.

It preceeds (and does not change) the code that is already there to limit the
stack to MAX_REFLOW_DEPTH to avoid crashing on stack overflow.

The above algorithm works well for the URLs(*) that has been reported, but
in retrospect, something like this would probably also work:
at 80% ignore all kFontStyle (regardless of what is currently on the stack)
at 90% ignore all kPhrase also

* http://www.vpnavy.org/vp9_shipmates.html still has problems
(Assignee)

Comment 96

14 years ago
Comment on attachment 156541 [details] [diff] [review]
Patch rev. 2

I have found out a new improvement that also fixes
http://www.vpnavy.org/vp9_shipmates.html
Attachment #156541 - Attachment is obsolete: true
Attachment #156541 - Flags: review?(bzbarsky)
(Assignee)

Comment 97

14 years ago
Created attachment 156698 [details] [diff] [review]
Patch rev. 3

at 80% of MAX_REFLOW_DEPTH ignore all kFontStyle tags
at 90% ignore all kPhrase tags too

Also fix a spot that had previously been overlooked - the transient style
stack,
which caused sink containers to be opened without any depth checks at all.
(Assignee)

Updated

14 years ago
Attachment #156698 - Flags: review?(bzbarsky)
> That is essentially what the patch does.

No, it blocks opening of "real" stylistic tags too, not just of residual style... 

What I was actually asking is whether it's enough to just do the
OpenTransientStyles() change (that's what handles opening up residual style) or
whether the WillHandleStartTag() change is also needed for the typical instance
of this bug.
*** Bug 224994 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 100

14 years ago
*** Bug 226512 has been marked as a duplicate of this bug. ***
Blocks: 260548
Blocks: 261748
Comment on attachment 156698 [details] [diff] [review]
Patch rev. 3

Marking r- to get a response...
Attachment #156698 - Flags: review?(bzbarsky) → review-
(Assignee)

Comment 103

14 years ago
*** Bug 275419 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 104

14 years ago
*** Bug 278358 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 105

14 years ago
(In reply to comment #98)
> What I was actually asking is whether it's enough to just do the
> OpenTransientStyles() change ...

Of the URLs that still have problems and that are fixed by the attached patch,
40% is fixed by the OpenTransientStyles() change alone.
OK.  So sounds like we really do want both changes then.  Is "Patch rev. 3"
current enough to review?
(Assignee)

Comment 107

14 years ago
Yes
Comment on attachment 156698 [details] [diff] [review]
Patch rev. 3

sr=bzbarsky; Blake, could you check on this too, since you've been dealing with
this code a lot?
Attachment #156698 - Flags: superreview+
Attachment #156698 - Flags: review?(mrbkap)
Attachment #156698 - Flags: review-
Comment on attachment 156698 [details] [diff] [review]
Patch rev. 3

r=mrbkap
Attachment #156698 - Flags: review?(mrbkap) → review+
(Assignee)

Comment 110

14 years ago
Checked in 2005-01-16 16:10 PDT

We still don't render deeply nested elements in well-formed documents -
that problem is bug 256180.

-> FIXED
No longer blocks: 205564
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 111

14 years ago
*** Bug 282701 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Blocks: 163993

Updated

13 years ago
No longer blocks: 163993

Comment 112

13 years ago
Rendering failure still occurs for CENTER tag (see bug 309658), probably others.

BTW, what does Gecko do with unclosed TD tags (for example)? Presumably when the
next such tag appears, the previous one is closed (and popped from the stack)?

Every paired tag that Gecko recognizes should belong in one of these two
categories, either ignore excess or close upon next instance. None should be
allowed to overflow blindly.

Updated

13 years ago
Blocks: 256180
*** Bug 310727 has been marked as a duplicate of this bug. ***

Comment 114

13 years ago
*** Bug 318131 has been marked as a duplicate of this bug. ***

Comment 115

13 years ago
*** Bug 323247 has been marked as a duplicate of this bug. ***

Updated

10 years ago
Summary: [FIX] No rendering after tag nesting/TAGVL has been exceeded → [FIX] No rendering after tag nesting/TAGLVL has been exceeded

Comment 116

7 years ago
Hi,
The status of the bug is Resolved. From where can I find the fix for this issue.

thanks in advance
(Assignee)

Comment 117

7 years ago
See comment 110.
Whiteboard: [evil, no </font>, many <font>] [patch] → [evil, no </font>, many <font>] [See comment 110]
It's never been fixed, only a workaround applied to make the issue less visible and then moved to a different bug number as bug 256180.

Comment 119

7 years ago
(In reply to comment #118)
> It's never been fixed, only a workaround applied to make the issue less
> visible and then moved to a different bug number as bug 256180.

Thanks for the reply Michal. Can you share how I can apply the workaround for my installed Firefox. In the attach I see the code files which have been modified.

Comment 120

7 years ago
(In reply to comment #119)
> Can you share how I can apply the workaround for my installed Firefox.
This bug was fixed in 2005, more than 6 years ago, so just use any recent Firefox version. If you still have problems, it might be either bug 256180, or a separate issue.
You need to log in before you can comment on or make changes to this bug.