4.70 MB, video/avi
85.97 KB, application/zip
3.75 KB, patch
|Details | Diff | Splinter Review|
6.64 KB, patch
|Details | Diff | Splinter Review|
530 bytes, text/html
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.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsCSSFrameConstructor::CreateContinuingFrame(nsPresContext*, nsIFrame*, nsContainerFrame*, bool)]
Component: Untriaged → Print Preview
Ever confirmed: true
Product: Firefox → Core
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?
Flags: needinfo?(mats) → needinfo?(dholbert)
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
Assignee: nobody → mats
Attachment #8527121 - Flags: review?(roc)
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/ .
Attachment #8527121 - Flags: review?(roc) → review+
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.