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
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
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.
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...
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.
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).
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?
*** 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)?
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. ***
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.
*** Bug 261748 has been marked as a duplicate of this bug. ***
*** Bug 260548 has been marked as a duplicate of this bug. ***
*** Bug 254767 has been marked as a duplicate of this bug. ***
*** Bug 302319 has been marked as a duplicate of this bug. ***
*** Bug 322394 has been marked as a duplicate of this bug. ***
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).
Should this bug's summary be changed now that bug 58917 is fixed?
See also bug 452038 for increasing the maximum tag nesting limit.
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).
Happens for me as well: https://forum.selfhtml.org/self/2015/sep/18/hilfe-aktuelle-farblink/1650592#tree-m1650592 *bump*
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 ;)
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.
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.