###!!! ASSERTION: wrong kind of child frame: 'aIsBlock == f->GetStyleDisplay()->IsBlockLevel()', file /Users/admin/trunk/mozilla/layout/generic/nsLineBox.cpp, line 74

Basically, the binding allows styling by the document... So we end up with a nsAutoRepeatBoxFrame that has: 1) display:list-item 2) float:right and is being inserted into the in-flow child list of its parent(!). Note that after the assert this bug is on we get: ###!!! ASSERTION: How'd we get a floated inline frame? The frame ctor should've dealt with this.: 'aReflowState.mStyleDisplay->mFloats == NS_STYLE_FLOAT_NONE', file ../../../mozilla/layout/generic/nsLineLayout.cpp, line 1225

Note that in this case we hit the following code in the frame constructor: 6499 // xul does not support absolute positioning 6500 nsIFrame* geometricParent = aParentFrame; That's probably bogus; definitely when aParentFrame is not a XUL frame. I have no idea what the behavior of floated or positioned XUL should be in general, however...

Well I don't see how float can apply to XUL; as for absolute positioning xul already has a way to achieve that so a second way is unnecessary but unharmful.

> Well I don't see how float can apply to XUL; <html:div> <xul:hbox style="float:left"/> </html:div> That's basically what happens in the testcase, fwiw. As in, the problem is not with "all XUL" the problem is when XUL interacts with normal CSS layout.

Sorry, I had assumed the parent was XUL; floating XUL in HTML is fine with me.

So if we had an IsFrameOfType() flag for XUL we could probably test the parent here, and if the parent is non-XUL we'd do the normal floating/positioning thing.... Seem reasoanble?

That wouldn't work so hot if parent is an inline whose parent is XUL, actually... Sounds to me like XUL should push a null float containing block while processing children. Possibly also a null absolute containing block. Thoughts?

WFM on trunk. I see ###!!! ASSERTION: no common ancestor at all???: 'parent', file /Users/jruderman/trunk/mozilla/layout/base/nsLayoutUtils.cpp, line 356 but that's a very frequent assertion and is covered by other bugs.

Crashtest checked in.