Bug 565125 and bug 564974. Make sure to null out our sibling pointers even if our parent goes away due to gc. r=jst

This commit is contained in:
Boris Zbarsky 2010-05-11 23:34:49 -04:00
Родитель 1d92002f2d
Коммит 0c29eabe93
3 изменённых файлов: 40 добавлений и 0 удалений

Просмотреть файл

@ -0,0 +1,27 @@
<!DOCTYPE html>
<html>
<head>
<script>
function boom()
{
var a = document.createTextNode(" ");
(document.documentElement).appendChild(a);
var b = document.createElement("span");
(document.documentElement).appendChild(b);
var c = document.createTextNode(" ");
(document.documentElement).appendChild(c);
var r = document.createRange();
r.setStart(a, 0);
r.setEnd(c, 0);
try {
r.surroundContents(document.documentElement);
} catch(e) {
}
document.documentElement.appendChild(b);
}
</script>
</head>
<body onload="boom();"></body>
</html>

Просмотреть файл

@ -65,3 +65,4 @@ load 552651.html
load 558973.html
load 564079-1.html
load 564114.html
load 565125-1.html

Просмотреть файл

@ -666,6 +666,18 @@ nsAttrAndChildArray::Clear()
// making this PR_FALSE so tree teardown doesn't end up being
// O(N*D) (number of nodes times average depth of tree).
child->UnbindFromTree(PR_FALSE); // XXX is it better to let the owner do this?
// Make sure to unlink our kids from each other, since someone
// else could stil be holding references to some of them.
// XXXbz We probably can't push this assignment down into the |aNullParent|
// case of UnbindFromTree because we still need the assignment in
// RemoveChildAt. In particular, ContentRemoved fires between
// RemoveChildAt and UnbindFromTree, and in ContentRemoved the sibling
// chain needs to be correct. Though maybe we could set the prev and next
// to point to each other but keep the kid being removed pointing to them
// through ContentRemoved so consumers can find where it used to be in the
// list?
child->mPreviousSibling = child->mNextSibling = nsnull;
NS_RELEASE(child);
}