1694844 - New Print dialog fails to open on Linux with no printer installed (I use print to file)

Status: RESOLVED FIXED

(Toolkit :: Printing, defect)

Description

[dickvl]

Attachment: screenshot of Browser Console showing the exception

With the new print dialog enabled (print.tab_modal.enabled = true) I only see the spinning loader when I open the Print dialog.
Neither the menu not the preview window is populated.

The Browser console shows this error message:

Exception { name: "NS_ERROR_FAILURE", message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPrinterList.systemDefaultPrinterName]", result: 2147500037, filename: "chrome://global/content/print.js", lineNumber: 903, columnNumber: 0, data: null, stack: "getPrintDestinations@chrome://global/content/print.js:903:32\n", location: XPCWrappedNative_NoHelper }```

Comment 1

[Tom S [:evilpie]]

Do you have CUPS installed at all? For good measure your about:support info might be useful.

Comment 2

[Tom S [:evilpie]]

Attachment: Bug 1694844 - Handle systemDefaultPrinterName throwing in print preview. r?emilio

After making this code more failure tolerant we can now print to pdf without working CUPS.
I verified this by having nsCUPSShim::InitOkay return false.

An alternative fix would be to have nsPrinterListCUPS::SystemDefaultPrinterName not return
NS_ERROR_FAILURE.

Maybe the other try..catch uses in getPrintDestinations should actually just swallow
errors as well. But they don't seem to fail when CUPS is disabled.

Comment 3

[Tom S [:evilpie]]

Attachment: Bug 1694844 - In nsPrinterListCUPS::SystemDefaultPrinterName return NS_OK even without working CUPS. r?emilio

The other nsPrinterListCUPS methods already handle !InitOkay() without returning an error or rejecting
the promise.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/15848a7e2b5a
In nsPrinterListCUPS::SystemDefaultPrinterName return NS_OK even without working CUPS. r=emilio

Comment 5

[Tom S [:evilpie]]

Comment on attachment 9206901 [details]
Bug 1694844 - In nsPrinterListCUPS::SystemDefaultPrinterName return NS_OK even without working CUPS. r?emilio

Beta/Release Uplift Approval Request

• User impact if declined: In rare cases where CUPS doesn't work the print preview is totally broken. With this at least Print to PDF works.
• 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): Low risk. Just makes a function not fail and return an empty string. We already do this in other similar cases.
• String changes made/needed:

Comment 6

[Tom S [:evilpie]]

I manually tested this by forcibly disabling CUPS in our code and testing that the print preview opens.

Comment 7

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/15848a7e2b5a

Comment 8

[dickvl]

I can confirm that the current Nightly build fixes it for me and the new print dialog opens instantly.

Thanks for the quick fix.

Comment 9

[Tom S [:evilpie]]

Great! Thanks for testing.

Comment 10

[Julien Cristau [:jcristau] (back April 22)]

Comment on attachment 9206901 [details]
Bug 1694844 - In nsPrinterListCUPS::SystemDefaultPrinterName return NS_OK even without working CUPS. r?emilio

approved for 87.0b8

Comment 11

[Julien Cristau [:jcristau] (back April 22)]

https://hg.mozilla.org/releases/mozilla-beta/rev/b301d2435826

Comment 12

[dickvl]

Confirmed.
87.0b7 doesn't work.
87.0b8 does work.