Closed Bug 1655474 Opened 4 months ago Closed 4 months ago

Crash in [@ nsPrintJob::UpdateSelectionAndShrinkPrintObject]


(Core :: Print Preview, defect, P2)

80 Branch



81 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox78 --- unaffected
firefox79 --- unaffected
firefox80 --- verified
firefox81 --- verified


(Reporter: alice0775, Assigned: emilio)




(Keywords: crash, regression)

Crash Data


(3 files)

This bug is for crash report bp-3ff79794-67a2-4d38-857b-5fc710200727.

Top 10 frames of crashing thread:

0 xul.dll nsPrintJob::UpdateSelectionAndShrinkPrintObject layout/printing/nsPrintJob.cpp:1845
1 xul.dll nsPrintJob::ReconstructAndReflow layout/printing/nsPrintJob.cpp:1414
2 xul.dll nsPrintJob::SetupToPrintContent layout/printing/nsPrintJob.cpp:1464
3 xul.dll nsPrintJob::FinishPrintPreview layout/printing/nsPrintJob.cpp:2804
4 xul.dll nsPrintJob::MaybeResumePrintAfterResourcesLoaded layout/printing/nsPrintJob.cpp:1725
5 xul.dll nsPrintJob::OnStateChange layout/printing/nsPrintJob.cpp:1746
6 xul.dll nsDocLoader::DoFireOnStateChange uriloader/base/nsDocLoader.cpp:1331
7 xul.dll nsDocLoader::FireOnStateChange uriloader/base/nsDocLoader.cpp:1294
8 xul.dll nsDocLoader::doStopURLLoad uriloader/base/nsDocLoader.cpp:898
9 xul.dll nsDocLoader::OnStopRequest uriloader/base/nsDocLoader.cpp:622


  1. Open about:preferences
  2. File > Print Preview
    --- Observe, Print preview preparing would not finish forever --- maybe another bug.
  3. Click on [X] button of main browser window controls
  4. Cancel print preview preparing dialog and click on [Close] button of print preview toolbar

Actual Results:
Browser crashes

Expected results:
Print preview will close, and return to normal browser

Seems the same as bug 1655179, which should be in the next nightly. Is it fixed by it?

Flags: needinfo?(alice0775)
Attached file about:support

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

Seems the same as bug 1655179, which should be in the next nightly. Is it fixed by it?

I can still reproduce the crash on Nightly80.0a1(20200727095125)


Build Configuration

Built from

Build platform

Flags: needinfo?(alice0775)

Oh, indeed, hadn't realized that patch had made it to nightly already. I can repro too, and looking then, thank you for filing this!

Assignee: nobody → emilio
Flags: needinfo?(emilio)

When we create a static document for printing, we clone all elements,
including <link rel=localization>. This means that
LocalizationLinkAdded/Removed etc do run for these documents.

However these documents don't come from the parser, which means that
we do block layout, but TriggerInitialTranslation and such do not run.

So we leave a stray onload blocker that we wait for as of bug 1648064,
so we wait forever and that is obviously not good.

Prevent these documents from using l10n, so as to avoid the problematic

This is a pre-existing issue that could already happen before the
regressing bug but seems worth addressing anyways.

If we're destroying we're definitely not going to be able to print, so
return an error rather than crashing in funny ways otherwise.

Depends on D85038

Severity: -- → S2
Flags: needinfo?(emilio)
Priority: -- → P2
Keywords: leave-open
Pushed by
Prevent static documents from using l10n. r=zbraniecki
Keywords: leave-open
Pushed by
Don't crash when trying to resume print while the page is closing. r=jwatt
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)

Comment on attachment 9166368 [details]
Bug 1655474 - Prevent static documents from using l10n. r=zbraniecki

Beta/Release Uplift Approval Request

  • User impact if declined: crashes / infinite-loading when printing built-in images.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: comment 0
  • List of other uplifts needed: none
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This patch on its own is pretty low-risk and it's early in the cycle, but if more stability issues come up with the regressing bug we should be ready to back it out.
  • String changes made/needed: none
Flags: needinfo?(emilio)
Attachment #9166368 - Flags: approval-mozilla-beta?
Attachment #9166369 - Flags: approval-mozilla-beta?

Comment on attachment 9166368 [details]
Bug 1655474 - Prevent static documents from using l10n. r=zbraniecki

approved for 80.0b3

Attachment #9166368 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #9166369 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Reproduced this issue using Firefox 81.0a1 (BuildId:20200727203201) on Ubuntu 18.04 64bit.

This issue is verified fixed using Firefox 81.0a1 (BuildId:20200802214843) and Firefox 80.0b3 (BuildId:20200803045446) on Windows 10 64bit & Ubuntu 18.04 64bit.

Flags: qe-verify+
OS: Windows 10 → All
Hardware: Desktop → All
You need to log in before you can comment on or make changes to this bug.