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

Status: RESOLVED FIXED

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

Description

[Andre Ulli]

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

Comment 1

[Asa Dotzler [:asa]]

over to layout. note, bug 18480 was about a _Crash_ on this page.  no longer
crashing but page fails to lay out completely

Comment 2

[timeless]

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.

Comment 3

[harishd]

Rickg, is this related to the stack overflow problem??

Comment 4

[timeless]

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

[bsharma]

updated qa contact.

Comment 6

[Alexey Chernyak]

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

Comment 7

[Alexey Chernyak]

bug 76457 has a nice testcase which does the counting for you.

Comment 8

[Boris Zbarsky [:bzbarsky]]

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"> ....

Comment 9

[Christopher Hoess (gone)]

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

Comment 10

[Christopher Hoess (gone)]

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...

Comment 11

[Christopher Hoess (gone)]

->harishd

Comment 12

[harishd]

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.

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Michal 'hramrach' Suchanek]

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.

Comment 16

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[Mike Doughney]

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.

Comment 20

[Bradley Baetz (:bbaetz)]

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

Comment 21

[Mats Palmgren (inactive)]

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

Comment 22

[Boris Zbarsky [:bzbarsky]]

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

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Andrew Schultz]

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

Comment 25

[Christopher Hoess (gone)]

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

Comment 26

[Kayjey]

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.

Comment 27

[Boris Zbarsky [:bzbarsky]]

Yes, it's a good idea to fix it.  Feel free to do so.  The fix involved
completely rearchitecting reflow.

Comment 28

[Kayjey]

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

Comment 29

[WD]

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

Comment 30

[Jason]

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.

Comment 31

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 32

[Jason]

"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...

Comment 33

[Boris Zbarsky [:bzbarsky]]

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

Comment 34

[Boris Zbarsky [:bzbarsky]]

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

Comment 35

[Boris Zbarsky [:bzbarsky]]

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

Comment 36

[Olivier Cahagne]

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

Comment 37

[Boris Zbarsky [:bzbarsky]]

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

Comment 38

[Chris Lyon]

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

Comment 39

[R.K.Aa.]

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

Comment 40

[Lewis Jardine]

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

[R.K.Aa.]

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

Comment 42

[Markus Hübner]

Reassigning to [e-mail]

Comment 43

[David D. Kilzer (ddk)]

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.

Comment 44

[David D. Kilzer (ddk)]

Attachment: 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).

Comment 45

[David D. Kilzer (ddk)]

Attachment: 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).

Comment 46

[David D. Kilzer (ddk)]

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.

Comment 47

[David D. Kilzer (ddk)]

Attachment: 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

Comment 48

[David D. Kilzer (ddk)]

Attachment: 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

Comment 49

[David D. Kilzer (ddk)]

Attachment: 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.

Comment 50

[David D. Kilzer (ddk)]

Attachment: 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.

Comment 51

[David D. Kilzer (ddk)]

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.

Comment 52

[Christian :Biesinger (don't email me, ping me on IRC)]

-> layout:tables per comment 50

Comment 53

[Bernd]

Attachment: content + frame dump

Comment 54

[Bernd]

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

Comment 55

[David D. Kilzer (ddk)]

-> reassign bug to default owner and QA contact for layout:tables per
   comment 52

Comment 56

[timeless]

tossing this bug around is totally pointless.

Comment 57

[Kayjey]

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

[Andrew Schultz]

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

Comment 59

[Ruslan Ismailov]

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

Comment 60

[Rob North]

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

Comment 61

[Christopher Hoess (gone)]

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

Comment 62

[Boris Zbarsky [:bzbarsky]]

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

Comment 63

[Boris Zbarsky [:bzbarsky]]

This happens outside tables too if the nesting depth is deep enough.

Comment 64

[Stefan Borggraefe]

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

Comment 65

[Mats Palmgren (inactive)]

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

Comment 66

[Mats Palmgren (inactive)]

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.

Comment 67

[Mats Palmgren (inactive)]

Attachment: 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...

Comment 68

[Mats Palmgren (inactive)]

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...

Comment 69

[Mats Palmgren (inactive)]

In addition to the testcases on this bug, here are a few more I collected from
from the duplicates:
http://wp.netscape.com/eng/mozilla/3.0/handbook/javascript/contents.htm
http://bugzilla.mozilla.org/attachment.cgi?id=90852&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=90869&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=94899&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=96437&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=101552&action=view
http://bugzilla.mozilla.org/attachment.cgi?id=104033&action=view
http://www.radiogoldindex.com/artistb.htm
http://www.malone.edu/academics/registrar/spring_text.cfm
http://www.rmis.rmfamily.com/sites/reguldol.php

Comment 70

[Mats Palmgren (inactive)]

Attachment: 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

[harishd]

>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.

Comment 72

[Mats Palmgren (inactive)]

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.

Comment 73

[Boris Zbarsky [:bzbarsky]]

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

Comment 74

[Hermann Schwab]

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

[Bernd]

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

Comment 76

[Steffen Wilberg]

tweaking summary to include the validator error "number of open elements exceeds
TAGVL (100)", see comment 43.

Comment 77

[Mats Palmgren (inactive)]

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

Comment 78

[Stefan Borggraefe]

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

Comment 79

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

[Kuba Suder]

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.

Comment 81

[Mats Palmgren (inactive)]

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

Comment 82

[Boris Zbarsky [:bzbarsky]]

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

Comment 83

[Boris Zbarsky [:bzbarsky]]

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

Comment 84

[Boris Zbarsky [:bzbarsky]]

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

Comment 85

[Mats Palmgren (inactive)]

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

Comment 86

[Dzyan de Palma]

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 !!!

Comment 87

[Boris Zbarsky [:bzbarsky]]

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

Comment 88

[Hermann Schwab]

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

Comment 89

[alanjstr]

Can someone update the patch?  It's probably bitrotted a bit after a year.

Comment 90

[Mats Palmgren (inactive)]

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

Comment 91

[Mats Palmgren (inactive)]

Taking bug...

Comment 92

[Mats Palmgren (inactive)]

Attachment: 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).

Comment 93

[Boris Zbarsky [: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?

Comment 94

[Boris Zbarsky [:bzbarsky]]

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

Comment 95

[Mats Palmgren (inactive)]

(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

Comment 96

[Mats Palmgren (inactive)]

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

Comment 97

[Mats Palmgren (inactive)]

Attachment: 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.

Comment 98

[Boris Zbarsky [: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.

Comment 99

[Blake Kaplan (:mrbkap) (inactive)]

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

Comment 100

[Mats Palmgren (inactive)]

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

Comment 101

[Boris Zbarsky [:bzbarsky]]

Mats?  Any update on the question in comment 98?

Comment 102

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 156698 [details] [diff] [review]
Patch rev. 3

Marking r- to get a response...

Comment 103

[Mats Palmgren (inactive)]

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

Comment 104

[Mats Palmgren (inactive)]

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

Comment 105

[Mats Palmgren (inactive)]

(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.

Comment 106

[Boris Zbarsky [:bzbarsky]]

OK.  So sounds like we really do want both changes then.  Is "Patch rev. 3"
current enough to review?

Comment 107

[Mats Palmgren (inactive)]

Yes

Comment 108

[Boris Zbarsky [:bzbarsky]]

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?

Comment 109

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 156698 [details] [diff] [review]
Patch rev. 3

r=mrbkap

Comment 110

[Mats Palmgren (inactive)]

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

Comment 111

[Richard Brodie]

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

Comment 112

[Frankie]

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.

Comment 113

[Dave Townsend [:mossop]]

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

Comment 114

[Richard Brodie]

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

Comment 115

[Alexis Wilke]

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

Comment 116

[b10238198]

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

thanks in advance

Comment 117

[Mats Palmgren (inactive)]

See comment 110.

Comment 118

[Michal 'hramrach' Suchanek]

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

[b10238198]

(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

[Steffen Wilberg]

(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.