Deeply nested elements are not rendered (TAGLVL has been exceeded)




13 years ago
10 months ago


(Reporter: Brian Krausz, Unassigned)


(Blocks: 5 bugs, {testcase})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments)



13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/2004081709

Note: I have also seen this problem in the 20040616 Windows build on XP, I
downloaded the 2004081709 to confirm it with the latest version and got the same

The problem was discovered on a phpbb forum, which is restricted to registered
users, so I copied the html and made another page for it (which is why some of
the images and none of the links work), doing my best to remove irrelevant code.

In addition to the nested tables not showing beyond a certain point (an already
reported bug), once the nesting reached a certain point, it seemed that the
browser was interperating the </table>'s but not the <table>'s, resulting in the
browser breaking out of the outermost tables prematurely.  The problem begins
slightly above , where you can see
that the "class=" is not taking effect after the "*flees in terror from the
cannibal quotes*".  Then onward from that it continues to break out of the
tables, until , when there is no
sign of tables besides the quotes.

Reproducible: Always
Steps to Reproduce:
2.Scroll up slightly, until you reach "*flees in terror from the cannibal quotes*"
3.Observe problem form there down.

Actual Results:  
Incorrect display

Expected Results:  
Displayed the same way as the top 4 posts.

No addition information

Comment 1

13 years ago
Also, my next post to the site brought it over to another page, so if you only
want to see the bug and not the correct post, head on over to

Comment 2

13 years ago
Created attachment 156529 [details]

Testcase showing behavior in both Mozilla and IE

Comment 3

13 years ago
Note that this behavior is also exhibited with 200 or more of any other
container element (span, div, blockquote, etc).  Tables, however, have a hard
limit of 50.

Comment 4

13 years ago
I do not experience the error in IE version 6.0.2800.1106
I'm not sure whether we should really mark bugs like this duplicate of bug
58917.  Probably not, since that one's about tags that should have been closed.
Taking bug, patch coming up...
Assignee: nobody → mats.palmgren
Component: Layout: Tables → HTML: Parser
Ever confirmed: true
Keywords: testcase
OS: Windows XP → All
Created attachment 156544 [details] [diff] [review]
Patch rev. 1

The current limit was set 03-Aug-2001, I think it's over-pessimistic for the
average PC today.
Attachment #156544 - Flags: review?(bzbarsky)
Maybe the deCOMtamination that's been done since then means that each level
uses less memory too?
Comment on attachment 156544 [details] [diff] [review]
Patch rev. 1

This has little to do with systems improving.  Stack size is generally limited
separately from memory.  Furthermore, deCOMtamination has little to do with
improving the amount of stack we use -- the main problem is the huge
nsHTMLReflowState, nsBlockReflowState, etc. objects we put on the stack.  One
big way of improving that would be to use the pres shell's StackArena for
allocating them -- I think there's a bug somewhere on doing that.

However, I'm against changing this without getting concrete numbers.  Also,
XP_MAC is dead (it's Classic Mac).
Attachment #156544 - Flags: review?(bzbarsky) → review-
FWIW, on Fedora Core 2,

$ ulimit -a | grep stack
stack size            (kbytes, -s) 10240
FWIW, on SuSE 9.1,
test@linux:~> ulimit -a|grep stack
stack size            (kbytes, -s) unlimited

Even on Fedora Core 2, isn't the number you have dynamically set by the OS
based on how much RAM there is?

Comment 12

13 years ago
*** Bug 259898 has been marked as a duplicate of this bug. ***
*** Bug 278348 has been marked as a duplicate of this bug. ***
(In reply to comment #9)
> However, I'm against changing this without getting concrete numbers.

   System (RAM)                       default ulimit -s (kilobytes)
1. Linux debian 2.2.20/i386 (256MB):  8192
2. Red Hat 9/i386 (1GB):              8192
3. FreeBSD 5.3/i386 (512MB):          65536
4. SuSE 8.?/i386 (128MB):             unlimited
5. Solaris 8/sparc (256MB):           8192
6. Windows XP+sp2/i386 (1GB):         2043 (according to cygwin ulimit)
7. SuSE 9.0/i386 (1GB):               unlimited
8. MacOSX 11.3/G4 (512MB):            8192

Test results (all builds with --disable-optimize & --enable-debug):
6. crash at frame depth 331 (Firefox static build)
7. Mozilla:
     ulimit -s      crash at frame depth
     800            292
     1024           375
     2043           753 (compare with XP's:331)
     2048           756
     4096           1518
     8192           3042
8. Camino:
     ulimit -s      crash at frame depth
     1024           368
     2048           744
     4096           1497
     8192           3004

So, for Linux/MacOSX a MAX_REFLOW_DEPTH of say 2800 seems safe.
For Windows I would suggest 300, I haven't tested 98/ME/2000 but
those could be verified using nightly builds?
For other systems we should probably stay with the current value 200
until we have figures.

Comment 15

13 years ago
The Mac situation is complicated.... apparently different OSX installs have the
stack depth limited very differently.  We've had JS engine crashes due to that,
Hmm, maybe we should actually calculate a max frame depth on platforms
that supports getrlimit(RLIMIT_STACK)?
Blocks: 205564
Severity: normal → major
Summary: Upon too many nested tables, Mozilla begins to break out of the outer tables incorrectly → Deeply nested elements are not rendered (TAGLVL has been exceeded)
suse, ulimit -s = unlimited.

i don't think 278348 is a dup of this. since 278348 have only one level nested

Comment 18

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


12 years ago
Blocks: 309658

Comment 20

12 years ago
Whether the tag is closed or unclosed, it should never be the case that Mozilla
just plain gives up and stops displaying content. The patch for bug 58917
watches over certain formatting tags and omits them if the stack depth reaches
dangerous levels.

Why not add a whole bunch more tags to that list? It would certainly be better
than letting half the page disappear into the void.
Depends on: 58917


12 years ago
Hardware: PC → All

Comment 21

12 years ago
*** Bug 261748 has been marked as a duplicate of this bug. ***

Comment 22

12 years ago
*** Bug 260548 has been marked as a duplicate of this bug. ***

Comment 23

12 years ago
*** Bug 254767 has been marked as a duplicate of this bug. ***

Comment 24

12 years ago
*** Bug 302319 has been marked as a duplicate of this bug. ***

Comment 25

11 years ago
*** Bug 322394 has been marked as a duplicate of this bug. ***

Comment 26

11 years ago
How much slower will this be on most architectures using a custom stack allocated on the heap rather than the callstack?  (I know it will be slower, but by how much?)  Is it possible to switch from using the system stack to using a custom stack data structure once the system stack gets close to full?

This would be accomplished by having a delegation function that creates the stack on the heap, a node at a time, and then calls each function that would be called at that place in the call hierarchy.

In fact, if there is one call per node in the DOM (i.e. if there is a 1-1 mapping between the DOM and the call hierarchy), this can handled without even allocating a new stack, by capturing the state of execution (any values passed up/down in the call hierarchy) in additional node properties, and then simply walking the DOM iteratively in some appropriate order (e.g. a depth-first postorder traversal).
Duplicate of this bug: 380822
Duplicate of this bug: 377056


10 years ago
Duplicate of this bug: 409263

Comment 30

9 years ago
Should this bug's summary be changed now that bug 58917 is fixed?


9 years ago
Blocks: 428727
Duplicate of this bug: 438395


9 years ago

Comment 32

9 years ago
See also bug 452038 for increasing the maximum tag nesting limit.
Duplicate of this bug: 453552
QA Contact: layout.tables → parser


8 years ago
Duplicate of this bug: 529585


7 years ago
No longer blocks: 309658
Duplicate of this bug: 309658
Blocks: 354161
Blocks: 730607
Setting dependency of bug 452038 pointed by comment #32, for ease of tracking.

TAGLVL referred in bug summary comes from;
After transfer to HTML5 parser, SGML is irrelevant because of HTML 5.  
Following is copy of bug 452038 comment #15.
> We don't seem to have TAGLVL anymore.  We do still have MAX_REFLOW_DEPTH
> (which as it happens is different on Mac Classic and WINCE from everything else).
Blocks: 452038
Duplicate of this bug: 911332


3 years ago
Depends on: 1073463


3 years ago
Duplicate of this bug: 1089044

Comment 39

2 years ago

Comment 40

2 years ago
Happens for me as well: *bump*
Duplicate of this bug: 1216353
Assignee: mats → nobody
Duplicate of this bug: 1247234
Blocks: 1254671

Comment 43

a year ago
Happens for me on

> 1st button "Cotisations sociales" > calculate

On the right side, next the table, are missing inputs

Works fully, for once, on IE and Edge ;)


a year ago
Duplicate of this bug: 1270866

Comment 45

a year ago
Guys, any update here? I have reports that users hit this on gmail when copy/paste to/from html mail. IE, Chrome and Chromium and Safari are reported as working, don't let people to switch from Firefox because of this bug.

Comment 46

10 months ago
AFAICT, the HTML parser part of this bug has been fixed for a while.
Component: HTML: Parser → Layout
I guess we may need to do the depth detection in the frame constructor rather than during reflow, so that we can flattern the tree when it's getting too deep.
You need to log in before you can comment on or make changes to this bug.