Crash in [@ nsPrintJob::ReflowPrintObject]
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
People
(Reporter: emilghitta, Assigned: bobowen)
References
(Blocks 1 open bug, )
Details
(Keywords: crash, regression)
Crash Data
Attachments
(3 obsolete files)
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
- Launch Firefox.
- Access the following link.
- Select <COUNTRY>USA</COUNTRY>
- Hit CTRL+P or CMD+P (on macOS)
- Select the “Selection” on Windows or “Print Selection Only” option on macOS.
- 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.
| Reporter | ||
Updated•11 months ago
|
Comment 1•11 months ago
|
||
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?
Updated•11 months ago
|
| Assignee | ||
Comment 2•10 months ago
|
||
(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.
| Assignee | ||
Comment 3•10 months ago
|
||
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.
| Assignee | ||
Comment 4•10 months ago
|
||
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
| Assignee | ||
Comment 5•10 months ago
|
||
Depends on D85008
Comment 6•10 months ago
|
||
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.
Updated•10 months ago
|
Updated•10 months ago
|
| Assignee | ||
Comment 7•10 months ago
|
||
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.
| Assignee | ||
Comment 8•10 months ago
•
|
||
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.
Updated•10 months ago
|
Updated•9 months ago
|
Comment 9•9 months ago
|
||
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.
Updated•7 months ago
|
Description
•