Closed Bug 1102791 Opened 7 years ago Closed 7 years ago

After opening "" clicking File > Print Preview Firefox is getting crashed.


(Core :: Print Preview, defect)

33 Branch
Not set



Tracking Status
firefox33 --- affected
firefox34 --- affected
firefox35 --- affected
firefox36 --- affected
firefox-esr31 --- affected


(Reporter: ashok, Assigned: mats)




(Keywords: crash)

Crash Data


(5 files)

Attached video FirefoxCrash.avi
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 "".
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.
Severity: normal → critical
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsCSSFrameConstructor::CreateContinuingFrame(nsPresContext*, nsIFrame*, nsContainerFrame*, bool)]
Component: Untriaged → Print Preview
Ever confirmed: true
Keywords: crash
Product: Firefox → Core
Regression window(m-i)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140203170607
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140203213206

Suspect: Bug 960822
Blocks: 960822
Keywords: regression
Flags: needinfo?(mats)
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
Blocks: 966419
No longer blocks: 960822
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");
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?
Flags: needinfo?(mats) → needinfo?(dholbert)
Not working on it at the moment. (Didn't dig any further than comment 5.)  Dive on in! :)
Flags: needinfo?(dholbert)
(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.
No longer blocks: 966419
Keywords: regression
OS: Windows 7 → All
QA Contact: mats
Hardware: x86_64 → All
Attached patch fix+testSplinter Review
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.
Assignee: nobody → mats
Attachment #8527121 - Flags: review?(roc)
FTR, here's a patch that adds support for overflow containers for
QA Contact: mats
Fwiw, the bug also affects so I suspect it affects all localized
versions of .
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.