Closed Bug 1771383 Opened 3 months ago Closed 2 months ago

Crash in [@ nsPrintJob::PrintDocContent]


(Core :: Printing: Output, defect)

Windows 7



103 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox101 --- unaffected
firefox102 + fixed
firefox103 --- fixed


(Reporter: mccr8, Assigned: mccr8)




(Keywords: crash, regression)

Crash Data


(1 file)

Crash report:


Top 10 frames of crashing thread:

0 xul.dll nsPrintJob::PrintDocContent layout/printing/nsPrintJob.cpp:1475
1 xul.dll nsPrintJob::SetupToPrintContent layout/printing/nsPrintJob.cpp:948
2 xul.dll nsPrintJob::MaybeResumePrintAfterResourcesLoaded layout/printing/nsPrintJob.cpp:1072
3 xul.dll nsPrintJob::InitPrintDocConstruction layout/printing/nsPrintJob.cpp:1019
4 xul.dll nsPrintJob::DoCommonPrint layout/printing/nsPrintJob.cpp:469
5 xul.dll nsPrintJob::CommonPrint layout/printing/nsPrintJob.cpp:352
6 xul.dll nsPrintJob::Print layout/printing/nsPrintJob.cpp:479
7 xul.dll nsDocumentViewer::Print layout/base/nsDocumentViewer.cpp:2937
8 xul.dll nsGlobalWindowOuter::Print dom/base/nsGlobalWindowOuter.cpp:5313
9 xul.dll mozilla::dom::BrowserChild::RecvPrint dom/ipc/BrowserChild.cpp:2522

Looks like a null deref.

Comment 0 seems to be a null-deref on aPO here:

// Called for each DocShell that needs to be printed
bool nsPrintJob::PrintDocContent(const UniquePtr<nsPrintObject>& aPO,
                                 nsresult& aStatus) {
  NS_ASSERTION(aPO, "Pointer is null!");
  aStatus = NS_OK;

  if (!aPO->mHasBeenPrinted && aPO->PrintingIsEnabled()) {
    aStatus = DoPrint(aPO);
    return true;

jwatt, is this possibly related to your recent cleanups?

Flags: needinfo?(jwatt)

Looking at the crash data, this is almost entirely Win7, but there's one Windows 10 crash right now:

(and this seems to be largely from window.print(), based on the reports we've looked at so far)

(Calling this a regression based on the crash data.)

Keywords: regression

High volume of crashes on beta, tracking for our 102 release.

Has Regression Range: --- → yes

Jonathan, can we please get somebody assigned rapidly to this bug? This is high volume on beta, I would take a patch next week for the RC. Thanks

jwatt hasn't been active on bugzilla for a few weeks. I'll write a patch.

Assignee: nobody → continuation

We're seeing a lot of null crashes here. Maybe we're running script since
we last checked mPrintObject and the printer was disconnected or
something along those lines, so just add a null check.

Pushed by
Null check mPrintObject in nsPrintJob::SetupToPrintContent(). r=emilio

Comment on attachment 9281413 [details]
Bug 1771383 - Null check mPrintObject in nsPrintJob::SetupToPrintContent().

Beta/Release Uplift Approval Request

  • User impact if declined: Crashes while printing under unknown circumstances (maybe if the printer is disconnected while in the middle of printing?).
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is just a null check. I think the worst that can happen is that we end up crashing a little later.
  • String changes made/needed: none
  • Is Android affected?: No
Attachment #9281413 - Flags: approval-mozilla-beta?
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 103 Branch

Comment on attachment 9281413 [details]
Bug 1771383 - Null check mPrintObject in nsPrintJob::SetupToPrintContent().

Thanks, this will be in our last beta tomorrow!

Flags: needinfo?(jwatt)
Attachment #9281413 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.