firefox crashes if print is selected
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
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)
(deleted),
text/x-phabricator-request
|
Details |
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
Reporter | ||
Comment 1•4 years ago
|
||
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.
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 3•4 years ago
|
||
Do you have a crash report that we could look at? See in about:crashes
.
Reporter | ||
Comment 4•4 years ago
|
||
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.
Comment 5•4 years ago
|
||
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?
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 6•4 years ago
|
||
(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.
Comment 7•4 years ago
|
||
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 | ||
Updated•4 years ago
|
Reporter | ||
Comment 8•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Comment 9•4 years ago
|
||
I don't think this is related directly to the B&W issue.
Assignee | ||
Comment 10•4 years ago
|
||
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.
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
Reporter | ||
Comment 13•4 years ago
|
||
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
Updated•4 years ago
|
Comment 14•4 years ago
|
||
Verified with 82.0b7 on Windows 10, Ubuntu 16x32; no crashes occured.
Marking bug verified as per this and comment 13 from Lee McFarland.
Description
•