User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.7) Gecko/2009021906 Firefox/3.0.7 Using javascript, composing a string of 250 open div tags followed by 250 closing div tags. At the 200th div, the tags are closed. Reproducible: Always Steps to Reproduce: 1. Compose string of 250 open div tags 2. Compose string of 250 closed div tags 3. document.write(string) or view generated source of attached minimal case Actual Results: <div>'s will start closing before the 200th div Expected Results: 250 nested divs Problem illustrated: http://douglasbeck.com/static/bugzilla-js-write-bug.html Should make a nice triangle of nested divs. Happens on PC & Mac

IIRC, parser or content sink has hard coded limit for DOM depth.

(In reply to comment #4) > http://mxr.mozilla.org/mozilla-central/source/parser/htmlparser/public/nsIHTMLContentSink.h#90 Interesting, that may help to explain what happens to <div>'s when nested 200x but it doesn't help explain the strange behavior when using other elements. Check out the generated source of the file I just added. You'll see: <div><div></div></div> - Correct. (but breaks @200) <p></p><p></p><p></p> - Wrong. 3 elements!? <a></a><a></a> - Wrong, immediately closed instead of nested <span><span></span></span> - Correct <h1></h1><h1></h1> - Wrong <h6></h6><h6></h6> - Wrong <blockquote><blockquote></blockquote></blockquote> - Correct I can't explain it. That's why I submitted a bug.

Some elements cannot contain some elements. An <a> element cannot contain another <a> element. Same for <p> and <hx>. This is spec'ed in the HTML5 parsing rules.

(In reply to comment #7) > Some elements cannot contain some elements. An <a> element cannot contain > another <a> element. Same for <p> and <hx>. This is spec'ed in the HTML5 > parsing rules. True, but I would argue that the behavior of javascript should not be modified, even if it's asked to generate HTML outside of spec. In the end this will cause more problems than it solves. If I have an error in my javascript but my generated code is correct, the error may be overlooked and portability suffers. If a programming language does not function in a strictly predictable manner, debugging is impossible. Especially if it is correcting code in an unpredictable way (creating three paragraph tags from two).

If you for some reason need to create "invalid" HTML, you can always use DOM methods which don't go via parser. document.createElement/element.appendChild/etc.

Won't be fixed as long as layout uses algorithms that are recursive along the depth of the tree.

Bug 354161?

Yeah. Thanks.