Closed Bug 1655474 Opened 4 months ago Closed 4 months ago

Crash in [@ nsPrintJob::UpdateSelectionAndShrinkPrintObject]

Categories

(Core :: Print Preview, defect, P2)

80 Branch
defect

Tracking

()

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

People

(Reporter: alice0775, Assigned: emilio)

References

(Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(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

STR:

  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
    OR
  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)
bp-d7cd91ac-f2c1-48aa-8af9-240270200727

about:buildconfig


Build Configuration

Source
Built from https://hg.mozilla.org/mozilla-central/rev/798bdad605b985a71cd204a56bb816dea503d432

Build platform
target
x86_64-pc-mingw32

*snip*
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
situation.

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 ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/32b46b511b32
Prevent static documents from using l10n. r=zbraniecki
Keywords: leave-open
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0506dfe2c979
Don't crash when trying to resume print while the page is closing. r=jwatt
Status: NEW → RESOLVED
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.

Status: RESOLVED → VERIFIED
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.