1699343 - printer dialog doesn't appear in some cases, with exception thrown for "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPrinterList.systemDefaultPrinterName]"

Status: RESOLVED FIXED

(Toolkit :: Printing, defect)

Description

[Daniel Holbert [:dholbert]]

In bug 1661751 comment 17, we got a report of someone unable to print in Firefox 86 (with the tab-modal print dialog), with this uncaught exception:

Uncaught (in promise) 
Exception   
columnNumber: 0
data: null
filename: "chrome://global/content/print.js"
lineNumber: 903
location: XPCWrappedNative_NoHelper { QueryInterface: QueryInterface(), filename: Getter, name: Getter, … }
message: "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPrinterList.systemDefaultPrinterName]"
name: "NS_ERROR_FAILURE"
result: 2147500037
stack: "getPrintDestinations@chrome://global/content/print.js:903:32\nasync*init@chrome://global/content/print.js:230:22\nasync*@chrome://global/content/print.js:91:45\nEventListener.handleEvent*@chrome://global/content/print.js:88:10\n"
<prototype>: ExceptionPrototype { toString: toString(), name: Getter, message: Getter, … }
print.js:903

It looks like print.js does indeed directly use systemDefaultPrinterName, here (added in bug 1658220):
https://searchfox.org/mozilla-central/rev/b7b156e53643f0237f3e98a76e5fc7fa9e3b4e71/toolkit/components/printing/content/print.js#908

const defaultPrinterName = printerList.systemDefaultPrinterName;

This isn't wrapped in try{} right now, but it probably needs to be wrapped in try{}, since this API can indeed fail -- the implementation on Windows is as follows:

nsresult nsPrinterListWin::SystemDefaultPrinterName(nsAString& aName) const {
  if (GetDefaultPrinterName(aName)) {
    return NS_OK;
  }
  return NS_ERROR_NOT_AVAILABLE;
}

https://searchfox.org/mozilla-central/rev/b7b156e53643f0237f3e98a76e5fc7fa9e3b4e71/widget/windows/nsDeviceContextSpecWin.cpp#592

emilio, maybe you could add try{}catch{} with some fallback code here, since you were looking at this area back in bug 1658220?

Comment 1

[Daniel Holbert [:dholbert]]

The reporter in bug 1661751 comment 17 was actually using Linux, i.e. our CUPS backend, I think. nsPrinterListCUPS::SystemDefaultPrinterName doesn't seem to have any obvious places where it could return anything other than NS_OK, so I'm not sure how it's failing in their case. But it does definitely look like it can fail on Windows as noted above, at least...

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Wasn't this fixed by bug 1694844, on Linux at least, effectively?

Comment 3

[Jimmie Mayfield]

Hi. Indeed this is a Linux system (Redhat Enterprise 7.9 x86-64). CUPS is running and there are two printers defined with one marked as default.

Based on bug 1694844, it smells like this might be fixed in FF 87. I'll give that a try when it's released. Thanks.

Comment 4

[Daniel Holbert [:dholbert]]

That's good news!

Would a similar fix make sense to the windows code that I quoted above, so that this API is reliably infallible? (It sounds like we're reasonably OK leaving the outparam-string empty, if that's what we did in bug 1694844?)

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Yes, I think so.

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: Bug 1699343: Adjust nsPrinterListWin::SystemDefaultPrinterName to make it infallible, like its CUPS-backed eqivalent. r?emilio

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/868eb9dbca08
Adjust nsPrinterListWin::SystemDefaultPrinterName to make it infallible, like its CUPS-backed eqivalent. r=emilio

Comment 8

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/868eb9dbca08