Crash report: https://crash-stats.mozilla.org/report/index/e9259672-2850-42b3-b419-97ec20200907

Top 10 frames of crashing thread:

0 xul.dll nsDocumentViewer::SetDocumentInternal layout/base/nsDocumentViewer.cpp:1858
1 xul.dll nsGlobalWindowOuter::Print dom/base/nsGlobalWindowOuter.cpp:5441
2 xul.dll nsFrameLoader::PrintPreview dom/base/nsFrameLoader.cpp:3286
3 xul.dll mozilla::dom::FrameLoader_Binding::printPreview_promiseWrapper dom/bindings/FrameLoaderBinding.cpp:884
4 xul.dll mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ConvertExceptionsToPromises> dom/bindings/BindingUtils.cpp:3227
5 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:599
6 xul.dll Interpret js/src/vm/Interpreter.cpp:3336
7 xul.dll js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:636
8 xul.dll JS::Call js/src/jsapi.cpp:2831
9 xul.dll mozilla::dom::IdleRequestCallback::Call dom/bindings/WindowBinding.cpp:865

Affected versions

• Firefox 81.0b7 (BuildId:20200906164749)
• Firefox 82.0a1 (BuildId:20200907094115)

Affected Platforms

• Windows 10 64bit.

Unaffected Platforms

• macOS 10.14
• Ubuntu 18.04 64bit

Steps to reproduce

1. Launch firefox.
2. Access any random webpage and print it via "Save to PDF"
3. Access about:sessionrestore.
4. Hit CTRL + P
5. Change the destination several times.

Expected Result

• FIrefox is stable.

Actual Result

• Firefox crashes.

Looks like the documentviewer's previous mDocument can be null, and the code here shouldn't assume it can deref it? The code in nsGlobalWindowOuter::Print has changed a bit recently, and I'm not sure if previously this couldn't happen, but now it can, or something...

#1 Regression window(cannot reproduce -> Preparing forever):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=94982363dfa4b5bde758cf1442a9166dc07c16fb&tochange=d6ae04588d3425c058afc56a47ba5345167ea04b

#2 Regression window(Preparing forever -> Crash):
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=886855bf6308c64ad2c459a73ba63317a8960070&tochange=47e9fdf7e93e8f3da410daa30b80b31567f3b488

I assume this is related to bug 1659470.

(In reply to :Gijs (he/him) from comment #1)

Looks like the documentviewer's previous mDocument can be null, and the code here shouldn't assume it can deref it? The code in nsGlobalWindowOuter::Print has changed a bit recently, and I'm not sure if previously this couldn't happen, but now it can, or something...

Yeah. Note that the previous mDocument should be valid basically (e.g. about:blank etc.). It looks like we call nsDocumentViewer::OnDonePrinting accidentally? (due to bug 1659470?)

I can just reproduce the crash with these steps;

1. Open whatever about pages (e.g. about: preferences)
2. Ctrl+P
3. Click "OK" button in the print preview error dialog
4. Change orientation in the print preview window

I'd say we should close the print preview window when the OK button in the error dialog is pressed until we fix bug 1659470?.

0. Please make sure the print destination is "Print to PDF".

I fixed the underlying error in the other bug, but null-checking here is harmless.

This shouldn't generally happen, but seems it can under some circumstances and
even though I've fixed the error condition that triggers this a null-check here is harmless.

https://hg.mozilla.org/mozilla-central/rev/10fc7701db1b

Please nominate this for Beta approval.

Comment on attachment 9174376 [details]
Bug 1663426 - Add a null-check to SetDocumentInternal. r=jwatt,bobowen

Beta/Release Uplift Approval Request

• User impact if declined: Crashes
• Is this code covered by automated tests?: No
• 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): null-check
• String changes made/needed: none

Comment on attachment 9174376 [details]
Bug 1663426 - Add a null-check to SetDocumentInternal. r=jwatt,bobowen

Approved for 81.0b9.

https://hg.mozilla.org/releases/mozilla-beta/rev/5a5144eb4ea2

https://testrail.stage.mozaws.net/index.php?/cases/view/1084762

Hello,

Confirming this issue as verified fixed on 82.0.2, 83.0b7 and 84.0a1 with Windows 10x64.