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

NEW
Unassigned

Status

()

Core
Layout
--
major
13 years ago
8 months ago

People

(Reporter: Brian Krausz, Unassigned)

Tracking

(Blocks: 5 bugs, {testcase})

Trunk
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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

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 http://nerdlife.net/mozilla/index.html#30446 , 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 http://nerdlife.net/mozilla/index.html#30447 , when there is no
sign of tables besides the quotes.

Reproducible: Always
Steps to Reproduce:
1.Goto http://nerdlife.net/mozilla/index.html#30446
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
(Reporter)

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
http://nerdlife.net/mozilla/index2.html

Comment 2

13 years ago
Created attachment 156529 [details]
Testcase

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

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.

Comment 6

13 years ago
Taking bug, patch coming up...
Assignee: nobody → mats.palmgren
Status: UNCONFIRMED → NEW
Component: Layout: Tables → HTML: Parser
Ever confirmed: true
Keywords: testcase
OS: Windows XP → All

Comment 7

13 years ago
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.

Updated

13 years ago
Attachment #156544 - Flags: review?(bzbarsky)

Comment 8

13 years ago
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.
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,
actually.
Hmm, maybe we should actually calculate a max frame depth on platforms
that supports getrlimit(RLIMIT_STACK)?

Updated

13 years ago
Blocks: 205564

Updated

13 years ago
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
table.
*** Bug 287629 has been marked as a duplicate of this bug. ***
*** Bug 303373 has been marked as a duplicate of this bug. ***

Updated

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

Updated

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

Updated

10 years ago
Duplicate of this bug: 380822

Updated

10 years ago
Duplicate of this bug: 377056

Updated

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?

Updated

9 years ago
Blocks: 428727

Updated

9 years ago
Duplicate of this bug: 438395
(Reporter)

Updated

9 years ago

Comment 32

9 years ago
See also bug 452038 for increasing the maximum tag nesting limit.

Updated

9 years ago
Duplicate of this bug: 453552
QA Contact: layout.tables → parser

Updated

8 years ago
Duplicate of this bug: 529585

Updated

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

FYI.
TAGLVL referred in bug summary comes from;
  http://www.w3.org/TR/html4/sgml/sgmldecl.html
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

Updated

4 years ago
Duplicate of this bug: 911332

Updated

3 years ago
Depends on: 1073463

Updated

3 years ago
Duplicate of this bug: 1089044

Comment 39

2 years ago
:( http://thedailywtf.com/articles/a-deeply-nested-mystery

Comment 40

2 years ago
Happens for me as well: https://forum.selfhtml.org/self/2015/sep/18/hilfe-aktuelle-farblink/1650592#tree-m1650592 *bump*

Updated

2 years ago
Duplicate of this bug: 1216353
Assignee: mats → nobody
Duplicate of this bug: 1247234
Blocks: 1254671

Comment 43

a year ago
Happens for me on 

http://web.maxirem.fr/

> 1st button "Cotisations sociales" > calculate

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

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

Updated

a year ago
Duplicate of this bug: 1270866

Comment 45

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