User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.111 Safari/537.36 Steps to reproduce: I am using Firefox V 33.1.1. Open "http://www.msn.com". Press Alt key to get menu bar. Select File > Print Preview. Same issue reproducible in Window 7, 8 and Ubantu Operating systems. Actual results: Firefox is getting crashed.

Regression window(m-i) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/ce3f48acc244 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140203170607 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/19b6dfafd05c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140203213206 Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ce3f48acc244&tochange=19b6dfafd05c Suspect: Bug 960822

In local build Last Good: ce3f48acc244 First Bad: 0b8fdcee7a26 Regressed by: 0b8fdcee7a26 Mats Palmgren — Bug 966419 - Update the global ShrinkToFitRatio when the current page overflows and requires additional scaling to fit horizontally on the page in Print/Preview. r=dholbert

From the crash report, it looks like we're actually aborting, not crashing. (though the experience is the same for the user) We abort in nsCSSFrameConstructor::CreateContinuingFrame, at the end of the if/else cascade, with: NS_RUNTIMEABORT("unexpected frame type"); https://hg.mozilla.org/mozilla-central/annotate/17e190839086/layout/base/nsCSSFrameConstructor.cpp#l8460

Yeah, looks like a <button> with an abs.pos. ::before that falls on a page boundary. It tries to create an overflow container. Daniel, are you working on this or should I take a look?

Not working on it at the moment. (Didn't dig any further than comment 5.) Dive on in! :)

(In reply to Mats Palmgren (:mats) from comment #6) > Yeah, looks like a <button> with an abs.pos. ::before that falls on a page > boundary. It tries to create an overflow container. (BTW: based on this ^ analysis, I'd bet that bug 960822 only "regressed" this by changing what thing happens to fall on the page-boundary. i.e. it's probably possible to reproduce this before that landed, with a carefully-constructed testcase where a <button> w/ ::after falls on a page-boundary, & whatever other factors are required.)

Yes, the correlation with bug 966419 is a coincidence. The crashtest also crashes FF28 for example.

I did consider supporting overflow containers, which would let us paginate the abs.pos. overflow, but it seems more consistent to not do that since we don't paginate normal flow content. https://tbpl.mozilla.org/?usebuildbot=1&tree=Try&rev=51c6c853985a

FTR, here's a patch that adds support for overflow containers for nsHTMLButtonControlFrame.

Fwiw, the bug also affects http://www.msn.com/sv-se/ so I suspect it affects all localized versions of http://www.msn.com/ .