See testcase, which crashes current trunk build on print preview. http://crash-stats.mozilla.com/report/index/3298fbd2-c9e8-41da-bc69-4173c2100626 0 xul.dll nsFrameManager::ReparentStyleContext layout/base/nsFrameManager.cpp:741 1 xul.dll nsFrameManager::ReparentStyleContext layout/base/nsFrameManager.cpp:747 2 xul.dll ReparentChildListStyle layout/generic/nsInlineFrame.cpp:315 3 xul.dll nsFirstLineFrame::Reflow layout/generic/nsInlineFrame.cpp:1038 4 xul.dll nsLineLayout::ReflowFrame layout/generic/nsLineLayout.cpp:853 5 xul.dll nsBlockFrame::ReflowInlineFrame layout/generic/nsBlockFrame.cpp:3722 6 xul.dll nsBlockFrame::DoReflowInlineFrames layout/generic/nsBlockFrame.cpp:3517 7 xul.dll nsBlockFrame::ReflowInlineFrames layout/generic/nsBlockFrame.cpp:3371 8 xul.dll nsBlockFrame::ReflowLine layout/generic/nsBlockFrame.cpp:2467 9 xul.dll nsBlockFrame::ReflowDirtyLines layout/generic/nsBlockFrame.cpp:1907 10 xul.dll nsBlockFrame::Reflow layout/generic/nsBlockFrame.cpp:1009 11 xul.dll nsBlockReflowContext::ReflowBlock layout/generic/nsBlockReflowContext.cpp:310 12 xul.dll nsBlockFrame::ReflowFloat layout/generic/nsBlockFrame.cpp:5634 13 xul.dll nsBlockReflowState::FlowAndPlaceFloat layout/generic/nsBlockReflowState.cpp:769 14 xul.dll nsBlockReflowState::AddFloat layout/generic/nsBlockReflowState.cpp:582 15 xul.dll nsLineLayout::ReflowFrame layout/generic/nsLineLayout.cpp:891 16 xul.dll nsBlockFrame::ReflowInlineFrame layout/generic/nsBlockFrame.cpp:3722 17 xul.dll nsBlockFrame::DoReflowInlineFrames layout/generic/nsBlockFrame.cpp:3517 18 xul.dll nsBlockFrame::ReflowInlineFrames layout/generic/nsBlockFrame.cpp:3371 19 xul.dll nsBlockFrame::ReflowLine layout/generic/nsBlockFrame.cpp:2467 20 xul.dll nsBlockFrame::ReflowDirtyLines layout/generic/nsBlockFrame.cpp:1907 21 xul.dll nsBlockFrame::Reflow layout/generic/nsBlockFrame.cpp:1009 22 xul.dll nsContainerFrame::ReflowChild layout/generic/nsContainerFrame.cpp:738 23 xul.dll nsContainerFrame::ReflowOverflowContainerChildren layout/generic/nsContainerFrame.cpp:935 24 @0x9a7337f

In a debug build I get a laundry list of assertions: ###!!! ASSERTION: Unexpected containers: 'SameCOMIdentity(debugDocContainer, debugDocShell)', file /Users/simon/mozwork/hgtree/mozilla/layout/base/nsDocumentViewer.cpp, line 2134 ###!!! ASSERTION: why CreateContinuingFrame for a non-splittable frame?: 'aFrame->GetSplittableType() != NS_FRAME_NOT_SPLITTABLE', file /Users/simon/mozwork/hgtree/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 8523 ###!!! ASSERTION: OOF must be first continuation: '!aFrame || !aFrame->GetPrevContinuation()', file /Users/simon/mozwork/hgtree/mozilla/layout/base/../generic/nsPlaceholderFrame.h, line 118 ###!!! ASSERTION: Broken frame linkage: 'prevSibling && prevSibling->GetNextSibling() == aFrame', file /Users/simon/mozwork/hgtree/mozilla/layout/generic/nsFrameList.cpp, line 132 ###!!! ASSERTION: Creating a circular frame list, this is very bad.: 'this != aNextSibling', file /Users/simon/mozwork/hgtree/mozilla/layout/base/../generic/nsIFrame.h, line 952 and then crash in nsIFrame::SetNextSibling (this and aNextSibling both null).

aFrame at this assertion is Placeholder(_moz_generated_content_before)(-1)@0x101f729f8

This gets rid of all the assertions (except the first one, which is bug 485893) and the crash. It passed tryserver. I don't know if the results are correct, because I can't work out from the testcase what the expected rendering is. Is there a way to make a crashtest out of this? Either by calling print preview during crashtests or maybe fiddling with the CSS? I assume that the "page-break-before" is what makes the crash depend on printing.

Do you need print preview in crashtests? If you just want a paginated crashtest, put class="reftest-print" on the root element.

Awesome, thanks, Boris!

Comment on attachment 454544 [details] [diff] [review] Patch (diff -w) dbaron's been working on float splitting lately...

Hmmm. This mess of propagating float break status through the inline break status goes away with the patches in bug 563584.

Fair enough, since branches aren't affected. Regression range for this is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d87974838fa9&tochange=e3e594837a30. Bug 492627 looks like a likely candidate, which makes sense since my patch is essentially just adding code from bug 492627 into another code path.

Mats checked in a smarter version of this patch in bug 570160

Checked in the testcase for luck: http://hg.mozilla.org/mozilla-central/rev/52dabce8b9d6

Verified fixed, using: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:2.0b2pre) Gecko/20100630 Minefield/4.0b2pre