Status

()

Core
HTML: Parser
11 years ago
3 years ago

People

(Reporter: Luke Hutchison, Unassigned)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1b2) Gecko/20060821 Firefox/2.0b2

I have a web page I'm trying to view which consists of some invalid HTML.  It is basically a series of several hundred tables, with each table containing a couple of other tables.  Some of the <table> tags are not terminated with a </table>.  This means that eventually the DOM reaches 128 nodes deep (rather than 10-12 as was intended by whoever wrote the code to view the page).  It turns out that Firefox is pruning the DOM at a depth of 128.  The page displays fine in Konqueror and IE, but is pruned on Firefox.

This is not likely to be the best way to handle this situation, even though I realize this was probably intentional to avoid layouts bringing the browser to its knees.

Perhaps the max number of levels should be raised to 1024, or lifted entirely?  Or child nodes added as siblings beyond a certain depth, so that at least the info doesn't actually disappear?  (I thought it was a missing record problem, then a server problem, then a browser bug, then I realized what was actually going on...)


Reproducible: Always

Comment 1

11 years ago
Can you create a minimized testcase that demonstrates the bug?
Assignee: nobody → general
Component: General → DOM
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch
(Reporter)

Comment 2

11 years ago
Created attachment 240074 [details]
Minimalistic test case

This test case contains 64 repeats of (erroneously-nested) HTML fragment; only 32  repeats actually show.  Additionally, repeats 1-30 show txt0 to txt7 correctly; repeat 31 shows only txt0, txt5, txt6 and txt7; and repeat 32 shows only txt0.  The text that actually shows is what remains above the depth of 128 at that point in the document.

Thanks!

Comment 3

11 years ago
Dup of bug 256180?
Assignee: general → nobody
QA Contact: ian → general

Updated

7 years ago
Component: DOM → HTML: Form Submission
QA Contact: general → form-submission
Let me try that again...
Component: HTML: Form Submission → HTML: Parser
QA Contact: form-submission → parser
The limit is now 200. The limit is going to stay in the parser as long as layout has algorithms that are recursive along the depth of the tree. :-(
Status: UNCONFIRMED → NEW
Depends on: 323394
Ever confirmed: true
Summary: DOM pruned at depth 128 → DOM pruned at depth 200
Duplicate of this bug: 485024

Updated

7 years ago
OS: Linux → All
Hardware: x86 → All
Version: 1.8 Branch → Trunk

Updated

7 years ago
Duplicate of this bug: 644196
(Reporter)

Comment 8

7 years ago
The DOM is presumably a DAG or tree, but should definitely be acyclic.  If so, why prune the depth at all?  If it is a limitation from the system stack running out of space, then why not implement a separate stack in the heap?  (I'm sure that's a lot of work, all the recursive calls have to be moved into a loop that works from the heapified stack etc. -- how much code would this touch?)
(In reply to comment #8)
> The DOM is presumably a DAG or tree, but should definitely be acyclic.

The DOM is a tree (with parent pointers).

> If so,
> why prune the depth at all?  

As already mentioned in the comment above yours, layout has algorithms that are recursive along the depth of the tree. This kind of recursion easily runs out of stack space on Windows in particular. To keep the behavior of Gecko consistent across platforms, the limit of 200 is the same even on platforms that have deeper runtime stacks than Windows has.

> If it is a limitation from the system stack
> running out of space, then why not implement a separate stack in the heap? 

I don't know, but my best guess is that there are always more important layout problems to deal with than rewriting recursive algorithms into iterative ones.

Updated

7 years ago
Blocks: 654164

Updated

6 years ago
Blocks: 667659

Updated

6 years ago
Blocks: 660776
Duplicate of this bug: 667659
Duplicate of this bug: 660776

Comment 12

6 years ago
As a note, the MSVC linker has an option to increase the stack size if necessary.
Duplicate of this bug: 728540
Blocks: 730607

Updated

6 years ago
Duplicate of this bug: 753344
Setting dependency to bug 256180 which is pointed in comment #3, for ease of tracking and search.
Depends on: 256180
You need to log in before you can comment on or make changes to this bug.