###!!! ASSERTION: StealFrame failure: 'NS_SUCCEEDED(rv)', file layout/generic/nsContainerFrame.cpp, line 1357 ###!!! ASSERTION: StealFrame: can't find aChild: 'removed', file layout/generic/nsContainerFrame.cpp, line 1264 ###!!! ASSERTION: frame to add has different parent: 'IsEmpty() || FirstChild()->GetParent() == aFrameList.FirstChild()->GetParent()', file layout/generic/nsFrameList.cpp, line 216 ###!!! ASSERTION: prev sibling has different parent: '!aPrevSibling || aPrevSibling->GetParent() == aFrameList.FirstChild()->GetParent()', file layout/generic/nsFrameList.cpp, line 219 ###!!! ASSERTION: this type of frame can't have overflow containers: '(aProperty != nsContainerFrame::OverflowContainersProperty() && aProperty != nsContainerFrame::ExcessOverflowContainersProperty()) || IsFrameOfType(nsIFrame::eCanContainOverflowContainers)', file layout/generic/nsContainerFrame.cpp, line 1438 And one I haven't seen before: ###!!! ASSERTION: Frames should be removed before destruction.: '!GetNextSibling() && !GetPrevSibling()', file layout/generic/nsFrame.cpp, line 454

Caused by something between fc7e928eaeae and af3668a89015, ie bug 10209.

This is only a "regression" from bug 10209 because it actually makes absolute positioning work there. nsresult nsContainerFrame::SetPropTableFrames(nsPresContext* aPresContext, nsFrameList* aFrameList, const FramePropertyDescriptor* aProperty) { NS_PRECONDITION(aPresContext && aProperty && aFrameList, "null ptr"); NS_PRECONDITION( (aProperty != nsContainerFrame::OverflowContainersProperty() && aProperty != nsContainerFrame::ExcessOverflowContainersProperty()) || IsFrameOfType(nsIFrame::eCanContainOverflowContainers), "this type of frame can't have overflow containers"); aPresContext->PropertyTable()->Set(this, aProperty, aFrameList); return NS_OK; } This assertion fails when SetPropTableFrame is called from nsOverflowContinuationTracker::Insert. The property is ExcessOverflowContainersProperty, and the frame is not eCanContainOverflowContainers. Should the columnset frames be changed to be eCanContainOverflowContainers?

Are we attaching abs-pos children to nsColumnSetFrame now? I'm actually not sure if we should be doing that, or attaching the abs-pos children to nsColumnSetFrame's anonymous block children. It depends on whether columnization should apply to abs-pos kids of the columns element or not.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #4) > Are we attaching abs-pos children to nsColumnSetFrame now? Yes. > I'm actually not sure if we should be doing that, or attaching the abs-pos > children to nsColumnSetFrame's anonymous block children. It depends on > whether columnization should apply to abs-pos kids of the columns element or > not. Hmm, that's a good point. I don't know either. Maybe bz or dbaron do?

The abspos containing block is formed by the first positioned ancestor's padding box edges. That would be nsColumnSetFrame, not the annonymous columns inside it.

OK. In that case, the columnset frames need to be able to contain overflow containers.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7) > OK. In that case, the columnset frames need to be able to contain overflow > containers. I tried doing that, and the first assertion gets fixed. The rest (and the crash) needs more investigation.

I think we're hitting this bug because we're not storing the continuations for absolute frames correctly <http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsAbsoluteContainingBlock.cpp#167>. We end up storing the continuation in the OverflowContainersProperty on the frame, and later on we don't look for it in that list <http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsColumnSetFrame.cpp#95>. Does anybody know of a good way to fix this?

Seems like we need to teach nsColumnSetFrame to use the OverflowContainersProperty list for overflow containers, yeah...

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10) > Seems like we need to teach nsColumnSetFrame to use the > OverflowContainersProperty list for overflow containers, yeah... roc, can anyone take care of this?

We probably have higher-priority stuff to work on.

Works for me in a local m-c ASan build on Linux64.

Still works for me in a local m-i debug build on Linux64.

Crash test: https://hg.mozilla.org/integration/mozilla-inbound/rev/a16036888ff3