This bug is for crash report bp-8440ef13-d122-46d4-a2a2-43b2e0200720.

Top 10 frames of crashing thread:

0 XUL nsPrintJob::ReflowPrintObject layout/printing/nsPrintJob.cpp:2003
1 XUL nsPrintJob::ReflowDocList layout/printing/nsPrintJob.cpp:1648
2 XUL nsPrintJob::InitPrintDocConstruction layout/printing/nsPrintJob.cpp:1674
3 XUL nsPrintJob::Observe layout/printing/nsPrintJob.cpp:2907
4 XUL mozilla::embedding::PrintProgressDialogChild::RecvDialogOpened toolkit/components/printingui/ipc/PrintProgressDialogChild.cpp:37
5 XUL mozilla::embedding::PPrintProgressDialogChild::OnMessageReceived ipc/ipdl/PPrintProgressDialogChild.cpp:228
6 XUL mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:8424
7 XUL mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2150
8 XUL mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1953
9 XUL mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:242

It seems that trying to print a specific xml element selection leads to tab crash

Affected versions

• 80.0a1 (BuildId:20200720094507)
• 79.0b9 (BuildId:20200717001501)
• 78.0.2 (BuilId:20200708170202)
• 68.10.0esr (BuildId:20200622191537)
• 78.0.2esr (BuildId:20200708170510)

Affected platforms

• Windows 10 64bit
• Ubuntu 18.04 64bit
• macOS 10.14

Steps to reproduce

1. Launch Firefox.
2. Access the following link.
3. Select <COUNTRY>USA</COUNTRY>
4. Hit CTRL+P or CMD+P (on macOS)
5. Select the “Selection” on Windows or “Print Selection Only” option on macOS.
6. Click the Ok/Print button.

Expected result

• Firefox is stable and the selection is successfully printed.

Actual result

• Tab Crash.

Regression Range

• This seems to be an old regression:
• Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c2248f85346939d3e0b01f57276c440ccb2d16a1&tochange=18a9cb5cb32d0e8031d0a80901b199d5e9827d83
• Possible Regressor: Since this is reproducible on older builds, unfortunately, mozregression keeps skipping builds.

Assuming this only affects selections in XML docs, it seems like a relatively niche case, hence marking S3. If it reproduces more widely, it'd probably deserve a higher severity given that it reliably crashes the tab from a simple user interaction.

The regression range in comment 0 includes bug 1419739, which sounds plausible as it is about printing a selection; Bob, can you take a look?

(In reply to Jonathan Kew (:jfkthame) from comment #1)

Assuming this only affects selections in XML docs, it seems like a relatively niche case, hence marking S3. If it reproduces more widely, it'd probably deserve a higher severity given that it reliably crashes the tab from a simple user interaction.

The regression range in comment 0 includes bug 1419739, which sounds plausible as it is about printing a selection; Bob, can you take a look?

Thanks, with the STR I should be able to track this down fairly quickly.

Even if this were used, we now rely on the selection being successfully cached
on the static clone used for printing, so the current implementation of
isRangeSelection might be misleading.

This also changes IsThereARangeSelection to work on the cached selection on the
static clone. This means that if we don't support cloning the selection, then we
won't offer to print a selection. This avoids frustation where a user might
think that they are printing a selection of a large document, when in fact we
are going to send the whole document to the printer.

Depends on D85007

Depends on D85008

Comment on attachment 9166313 [details]
Bug 1653981 part 1: Remove unused isRangeSelection from nsIWebBrowserPrint. r=jwatt!

Revision D85007 was moved to bug 1653334. Setting attachment 9166313 [details] to obsolete.

The fix for this got rolled into bug 1653334, because that made most of the changes in the patches I had here obsolete.
The patches for bug 1653334 are queued to land.

Bug 1653334 added a null check to prevent the crash here.
More importantly, I believe, the changes there mean we shouldn't offer the choice of printing a Selection when we don't support it.

I have reproduced this crash using the steps from comment 0, on an affected Nightly build 2020-07-20.

I can confirm that the options “Selection” on Windows/Ubuntu or “Print Selection Only” on macOS are displayed as grayed out, on Beta 81.0b8.