crash in nsPrintEngine::ReconstructAndReflow(bool)

VERIFIED FIXED in Firefox 30

Status

()

defect
--
critical
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: martijn.martijn, Assigned: Ms2ger)

Tracking

(4 keywords)

30 Branch
mozilla32
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox29 unaffected, firefox30 verified, firefox31 verified, firefox32 verified, b2g-v1.4 fixed, b2g-v2.0 fixed)

Details

(crash signature)

Attachments

(4 attachments)

Reporter

Description

5 years ago
Posted file parentframe2.htm
See testcase, load the testcase, the print dialog comes up, click on the print button. Result, crash.

The iframe consists of this source:
<html>
<head>
<script>
setTimeout(function() {window.print();window.location.href=window.location.href;}, 1000);
</script>

</head>

<body onbeforeunload="document.write('test')">
<style>
@font-face {
      font-family: "cutabovetherest";
      src: url("");
    }
* { font-family: "cutabovetherest"; }
</style>

mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm
<div style="page-break-before: avoid;page-break-after: right;"></div>
mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm mmmmm

</body>
</html>

This bug was filed from the Socorro interface and is 
report bp-60ffc46d-d59f-47d7-96e8-176da2140430.
=============================================================
0 	XUL 	nsPrintEngine::ReconstructAndReflow(bool) 	layout/base/nsPresContext.h
1 	XUL 	nsPrintEngine::SetupToPrintContent() 	layout/printing/nsPrintEngine.cpp
2 	XUL 	nsPrintEngine::AfterNetworkPrint(bool) 	layout/printing/nsPrintEngine.cpp
3 	XUL 	nsPrintEngine::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, tag_nsresult) 	layout/printing/nsPrintEngine.cpp
4 	XUL 	_ZThn8_N13nsPrintEngine13OnStateChangeEP14nsIWebProgressP10nsIRequestj12tag_nsresult 	layout/printing/nsPrintEngine.cpp
5 	XUL 	nsDocLoader::DoFireOnStateChange(nsIWebProgress*, nsIRequest*, int&, tag_nsresult) 	uriloader/base/nsDocLoader.cpp
6 	XUL 	nsDocLoader::FireOnStateChange(nsIWebProgress*, nsIRequest*, int, tag_nsresult) 	uriloader/base/nsDocLoader.cpp
7 	XUL 	nsDocLoader::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult) 	uriloader/base/nsDocLoader.cpp
8 	XUL 	_ZThn8_N11nsDocLoader13OnStopRequestEP10nsIRequestP11nsISupports12tag_nsresult 	obj-firefox/x86_64/uriloader/base/Unified_cpp_uriloader_base0.cpp
9 	XUL 	nsLoadGroup::RemoveRequest(nsIRequest*, nsISupports*, tag_nsresult) 	netwerk/base/src/nsLoadGroup.cpp
10 	XUL 	nsLoadGroup::Cancel(tag_nsresult) 	netwerk/base/src/nsLoadGroup.cpp
Reporter

Comment 1

5 years ago
Posted file crash1.htm
Iframe for testcase
Reporter

Comment 2

5 years ago
Posted file testcase
Reporter

Comment 3

5 years ago
Ok, the first testcase didn't crash, but the last testcase I attached does crash.
Last testcase crashes for me (in linux nightly) with signature  [@ nsPrintEngine::InitPrintDocConstruction(bool) ]

bp-30b5ac0a-d38a-4055-a93a-047e02140430

Comment 5

5 years ago
Crash: bp-33165a7b-eeae-4cf8-8cff-d1bd92140430

Regression window(m-c)
Good:
https://hg.mozilla.org/mozilla-central/rev/c71a1f6f6f2f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140208192902
Bad:
https://hg.mozilla.org/mozilla-central/rev/c8cd1f6b6d2d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Firefox/30.0 ID:20140209000603
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c71a1f6f6f2f&tochange=c8cd1f6b6d2d
OS: Mac OS X → All
Version: Trunk → 30 Branch

Comment 6

5 years ago
In local build,
Last Good: 7bec1b07e94f
First Bad: d30a9c28e77e

Triggered by: 
  	d30a9c28e77e	Ms2ger — Bug 968805 - Pass nsIDocument to nsIContentViewer.loadStart; r=smaug
Blocks: 968805
Assignee

Comment 7

5 years ago
Oh, I think I see it...

cv->LoadStart(static_cast<nsIHTMLDocument *>(this));

doesn't play well with the

             v nsIHTMLDocument
mDocument == aDocument
^ nsIDocument*

check. Not sure how to best solve it; add an aDontPrepareToStartLoad argument?
Flags: needinfo?(Ms2ger)
Assignee

Comment 8

5 years ago
OTOH, I'm pretty sure the PrepareToStartLoad call was never reached before.
Assignee

Comment 9

5 years ago
Before bug 968805, none of the callers would reach this branch. The callers in
nsContentDLF.cpp call LoadStart immediately after constructing the
nsDocumentViewer, so they hit the !mDocument case, and the comparison was
always false for the caller in nsHTMLDocument::Open, as it passed an
nsIHTMLDocument pointer, so the nsISupports pointers being compared were
always different. (XPCOM rules require SameCOMIdentity in this case, to avoid
exactly this issue.)
Attachment #8415889 - Flags: review?(bugs)
Assignee

Updated

5 years ago
Assignee: nobody → Ms2ger
Status: NEW → ASSIGNED
With changeset d30a9c28e77e backed out, the removed code isn't reached by attachment 8415595 [details] or anything we run on try.
Attachment #8415889 - Flags: review?(bugs) → review+
Comment on attachment 8415889 [details] [diff] [review]
Stop calling PrepareToStartLoad in nsDocumentViewer::LoadStart;

https://hg.mozilla.org/integration/mozilla-inbound/rev/e50544d1d32d

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 968805
User impact if declined: crashes when printing
Testing completed (on m-c, etc.): full try run + manual testing that the removed code was indeed dead; on mozilla-inbound
Risk to taking this patch (and alternatives if risky):  fairly low risk; it should revert our behaviour to what it was before bug 968805. Alternative is a backout of the regressing patch, which does change a uuid.
String or IDL/UUID changes made by this patch: none
Attachment #8415889 - Flags: approval-mozilla-beta?
Attachment #8415889 - Flags: approval-mozilla-aurora?
Comment on attachment 8415889 [details] [diff] [review]
Stop calling PrepareToStartLoad in nsDocumentViewer::LoadStart;

Approving for uplift as I see this landed on central:

http://hg.mozilla.org/mozilla-central/rev/e50544d1d32d
Attachment #8415889 - Flags: approval-mozilla-beta?
Attachment #8415889 - Flags: approval-mozilla-beta+
Attachment #8415889 - Flags: approval-mozilla-aurora?
Attachment #8415889 - Flags: approval-mozilla-aurora+
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Assignee

Updated

5 years ago
Keywords: checkin-needed
Keywords: checkin-needed
Target Milestone: --- → mozilla32
Reproduced in Nightly 2014-05-01, Win 7 x64.
Verified fixed 32.0a1 (2014-05-06).
Status: RESOLVED → VERIFIED
Reproduced the crash using old Nightly (2014-04-30) on Windows 7 64bit, verified that the issue is fixed using Firefox 30 beta 3 and latest Aurora on Mac OS X 10.9.2, Windows 7 64bit and Ubuntu 13.10 32bit.
You need to log in before you can comment on or make changes to this bug.