Boris Zbarsky wrote:
fantasai wrote:
1. Why do we call DeletingFrameSubtree before calling RemoveFrame?
Why doesn't RemoveFrame take care of unmapping the content itself?
(P.S. DeletingFrameSubtree is a really confusing name for something
that doesn't delete the subtree.)
I think the answer to this is that we'd sort of like to switch to
RemoveFrame just dealing. At least roc and I would.
So afaict the actual work of DeletingFrameSubtree &co is just these lines
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsCSSFrameConstructor.cpp#6938
// Remove the mapping from the content object to its frame.
nsIContent* content = aFrame->GetContent();
if (content) {
aFrameManager->RemoveAsPrimaryFrame(content, aFrame);
aFrameManager->ClearAllUndisplayedContentIn(content);
}
with the rest being recursion code. This is then followed up by a call
to nsFrameManager::RemoveFrame at the top level. Does that seem right?
Would it make sense for nsIFrame::RemoveFrame to unmap the content
itself? I'm not seeing it called anywhere outside the frame manager
and nsCSSFrameConstructor, and those calls are all preceded by
DeletingFrameSubtree.
http://mxr.mozilla.org/mozilla-central/search?string=RemoveFrame
~fantasai
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
