Closed Bug 1664172 Opened 4 years ago Closed 4 years ago

firefox crashes if print is selected

Categories

(Core :: Printing: Output, defect, P1)

Firefox 82
defect

Tracking

()

VERIFIED FIXED
82 Branch
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- unaffected
firefox80 --- unaffected
firefox81 --- unaffected
firefox82 --- verified

People

(Reporter: 6dnail, Assigned: alaskanemily)

References

(Regression)

Details

(Keywords: crash, regression, Whiteboard: [print2020_v82][old-ui-])

Crash Data

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

Selected File->Print

Actual results:

Firefox crashed

Expected results:

Print dialog should have come up

As of build 20200910093613, selecting print crashes firefox unless print.tab_modal.enabled is false (true is the default and will cause a crash).
My system is Ubuntu 16.04.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Printing: Output
Product: Firefox → Core

Do you have a crash report that we could look at? See in about:crashes.

Flags: needinfo?(6dnail)

The crash report was submitted. By the way, the first two lines in the crash report are:
Signature nsPrinterCUPS::EnsurePrinterInfo More Reports Search
UUID 5401ddfc-88e6-47c0-b026-9f4ad0200910

Some other details:
Build ID 20200910093613 (2020-09-10)
OS Ubuntu 16.04.6 LTS
Frame 0 is libxul.so nsPrinterCUPS::EnsurePrinterInfo(nsPrinterCUPS::CUPSPrinterInfo&) const

One time I saw what I think is the new print window/menu or whatever - this was visible for a fraction of a second before firefox disappeared into the 'firefox has crashed' dialog.

Flags: needinfo?(6dnail)

Thank you! That is https://crash-stats.mozilla.org/report/index/5401ddfc-88e6-47c0-b026-9f4ad0200910

It's an assertion (MOZ_RELEASE_ASSERT(aInOutPrinterInfo.mPrinterInfo)) that was added in bug 1661157.

It seems we may need to deal with this case somehow. Lee, do you have any disconnected printers or something in the CUPS interface or something?

Severity: -- → S1
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(emcdonough)
Priority: -- → P2
Regressed by: 1661157
Has Regression Range: --- → yes
Priority: P2 → P1
Crash Signature: [@ nsPrinterCUPS::EnsurePrinterInfo ]

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

Thank you! That is https://crash-stats.mozilla.org/report/index/5401ddfc-88e6-47c0-b026-9f4ad0200910

It's an assertion (MOZ_RELEASE_ASSERT(aInOutPrinterInfo.mPrinterInfo)) that was added in bug 1661157.

It seems we may need to deal with this case somehow. Lee, do you have any disconnected printers or something in the CUPS interface or something?

I do have some disconnected printers - and that would be a common thing. My main printer is accessed via the LAN. I also have installed on the system, a printer definition for that printer to cover any instance where the system that normally controls that printer were to be unavailable. Furthermore, my laptop (not used in this issue), also has the LAN printer defined. In the case of the laptop, at home with the LAN available, I regularly print on that printer however, when traveling, the printer obviously isn't available. I also use the firefox print dialog to access the printer known as 'print to file'. In short, you should see lots of disconnected printers in a Ubuntu environment.

FWIW, I'm on Ubuntu 20.04 and have a disconnected network printer, and I'm not able to reproduce this (no crashes on printing here in latest Nightly). So there's some additional subtlety to the required conditions here.

Assignee: nobody → emcdonough
Status: NEW → ASSIGNED
Flags: needinfo?(emcdonough)

The bug does not appear on Ubuntu 18.04 with last night's build so - it may be limited to Ubuntu 16.04, which is where the problems associated with B&W vs color printer are.

Whiteboard: [print2020_v82][old-ui-]

I don't think this is related directly to the B&W issue.

Add a separate field to CUPSPrinterInfo to track if we attempted to fetch the
printer info before.

This should be safe, as all the CUPS calls internally check for a null-dinfo
and we will detect the error at that point.

Pushed by emcdonough@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/def25c882166 Remove the MOZ_RELEASE_ASSERT on the CUPS dinfo r=emilio
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 82 Branch

As of this morning's Firefox nightly update, firefox no longer crashes when File->Print is selected. As for as I am concerned (the originator) this is not a problem. There are other issues with Print and - bugs open on the problems but at least now Firefox does not crash when attempting to work on print issues.
Thank you

Flags: qe-verify+

Verified with 82.0b7 on Windows 10, Ubuntu 16x32; no crashes occured.
Marking bug verified as per this and comment 13 from Lee McFarland.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: