(slightly edited frame dump to fit Bugzilla attachment size limit, the deleted sections are marked "[ ... stuff deleted ... ]" - I have the original if anyone needs it) This is with "Patch rev. 3" from bug 310638 (which does not walk the out-of-flow child lists), this makes us miss out-of-flow 0x8b6e9e0 (lime) because we had no placeholder for it (bug). Since this out-of-flow contains placeholders/ out-of-flows of its own, we miss those too. It proves that we have an external placeholder pointing into this set of trees we are about to Destroy. According to the FrameManager the offending placeholder is 0x8da3148 (magenta) and it's not on any child list. Following the its mParent chain gives 0x8b99e48 (yellow) as the first frame that is still in the tree. (the frame dump is after DoDeletingFrameSubtree() but before we start to remove the frames in the destroy queue)

Here's another error I found... I think it's related to the orphan placeholder but I'm not sure... I haven't analyzed any frame dumps on this yet. Let me know if you have any ideas on what the problem could be...

BTW, the bad reflow command normally causes a crash soon after the printout, that's why I removed it... (I'm not suggesting that is the solution)

So in "Dump 1" this ancestor of the placeholder that's in the tree is the "right" frame (the one that's a containing block for the abs-pos out of flow). And the placeholder's parents aren't dead, just lost? :( In "Trace 2", what triggers the warning: WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain, file nsCSSFrameConstructor.cpp, line 8179 and the assertion: ###!!! ASSERTION: not in child list: 'nsFrameList(aChildFrame->GetParent()->GetFirstChild(listName)) .ContainsFrame(aChildFrame)', file nsCSSFrameConstructor.cpp, line 1894 ? I really wish we could get minimal-ish testcases out of this stuff. :(

This is marked confidential because it deals with other confidential bugs and not because it is itself a separate security problem, right?

(In reply to comment #6) > This is marked confidential because it deals with other confidential bugs and > not because it is itself a separate security problem, right? > Yes.

Mats/bz, is this bug still useful?

I ran the tests in comment 0 to 100k without any crash. -> WORKSFORME