118214 - Top of document hierarchy disappears when nodes underneath still exist.

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect, P5)

Description

[Ray Whitmer]

Nodes within a document refer weakly to ancestors and the ownerDocument.  The
specified DOM behavior is that these continue to point to the referenced nodes
in the hierarchy and the ancestors and document do not disappear until all
references within the hierarchy are gone.  The specification does not really
allow for these references being weak.  An application may hold the reference to
the child expecting to be able to follow the ownerDocument or parentNode
attributes to get at information or services that are available there and are
integrally a part of the information model of the node.  The whole reason these
upward-pointing attributes were added was so that applications don't have to
keep explicit pointers to all parts of the graph they may need later.  If they
were expected to keep a pointer to these around all the time, they wouldn't need
them.

This is a difficult problem to solve, but it is not impossible.  First, the
document must know all nodes that were created by it and are externally
referenced.  There are several ways that this can be done.  It would need to
know this anyway to properly zero the ownerDocument and not leave stale pointers
when the document dies.  The document should refuse to die as long as nodes it
has created are still externally referenced (refcount of 1 with a null parent
pointer or refcount of 2 with a non-null parent pointer).

Also, every root node (other nodes that are not still in the hierarchy) must
refuse to die as long as descendants still exist that are externally referenced.
 There are also several ways this can be accomplished.

Since this last part only applies to the nodes that are currently in the same
hierarchy, no additional information is required.  I can give a more detailed
algorithm that probably won't noticably impact speed in cases that are not
broken today.  I believe that the memory size of a node will not need to change
beyond what may required to solve bug 118194.
But the fix might be a bit ugly.  The side effect (actually the feature we are
looking for here) is that if a DOM node leaks, the whole document will leak. 
But that is what I believe the DOM spec requires.

Comment 1

[Sivakiran Tummala]

changing priority to P3

Comment 2

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 3

[Hixie (not reading bugmail)]

I can't reproduce this. Any suggestions on how to force a GC from an ordinary Web page, to help check this? (I did manage to reproduce this bug in Safari!)

Comment 4

[Firefox Bug Husbandry Bot]

Bulk priority change, per :mdaly

Comment 5

[Anne (:annevk)]

As per comment 3.