Loading the testcase triggers: ###!!! ASSERTION: no common ancestor at all???: 'parent', file /Users/jruderman/trunk/mozilla/layout/base/nsLayoutUtils.cpp, line 374 ###!!! ASSERTION: aDocument must be current doc of aParent: '!aParent || aDocument == aParent->GetCurrentDoc()', file /Users/jruderman/trunk/mozilla/content/base/src/nsGenericElement.cpp, line 2000 ###!!! ASSERTION: element not in the document: 'doc', file /Users/jruderman/trunk/mozilla/layout/base/nsChildIterator.cpp, line 62 The second assertion is the "interesting" one. The only other time I saw it was in bug 389636, which Boris fixed a few months ago. There are existing bug reports on the other two assertions.

Well, this is fun. We're doing a frame reconstruct (probably due to that MozBinding change), and when we construct the frames for the kids of the anonymous <hbox> set up by the inner binding we end up with an nsAnonymousContentList in the content iterator, and this contains one insertion point, and this insertion point contains the <listboxbody>. I thought I'd fixed this sort of thing in bug 342954. :(

Oh, so the point is we construct a frame for the listboxbody, try to bind its anonymous kids, and assert. Perhaps we should assert in ConstructFrame that the content is actually in the right document, to catch this stuff better?

OK, so when we're in nsBindingManager::ContentRemoved, we find the nested insertion point (the anon hbox). Then we do the GetXBLChildNodesInternal thing on the insertion point and get back an nsAnonymousContentList that contains the <listboxbody>. But there's _also_ an entry for the insertion point in the mContentListTable, and that's _another_ nsAnonymousContentList that contains the <listboxbody>. It does make sense that there would be an entry in the mContentListTable, since that hbox has a <children> as a kid. And it makes sense that there would be an entry in the mAnonymousNodesTable (which is where the list we end up getting comes from), since the node has a binding and the binding's <content> contains a <children> directly. Oh, and neither of the insertion points in those two lists is a pseudo insertion point; both have an index of 0. That's kind of odd. So it looks like we need to remove from both types of list on the insertion point. And possibly do that for all the insertion points in between the non-anon parent and the nested insertion point, depending on where XBL is sticking this pointer. :( smaug, want to learn some more about XBL?

Martijn, this sort of thing is why we want to drop XBL1 and implement XBL2, for what it's worth...

It's just an assertion, no? Happens all the time.

Come to think of it, why is the content iterator getting the other anonymous nodelist? It should just be getting the XBL childnodes, I would have thought... And it's not "just an assertion". It's an assertion that happens because XBL screws up its data structures beyond belief, and that screwage is causing some pretty bad behavior (constructing frames for a node that's not in the document).

Ok, sorry, that was lame of me. I don't really why XBL is to blame here, though (but probably best to not pollute this bug any further by my ignorance).

(In reply to comment #5) > It's just an assertion, no? Happens all the time. We are working toward running assertion-clean and then enforcing this on test boxes: bug 279923, bug 404077

Not blocking on this.

Fixed by the patch in bug 514300.