Closed Bug 1790757 Opened 2 years ago Closed 2 years ago

crash displaying print popup | this.availablePrinters[target.printerName] is undefined

Categories

(Toolkit :: Printing, defect, P3)

Firefox 104
defect

Tracking

()

RESOLVED FIXED
110 Branch
Tracking Status
firefox110 --- fixed

People

(Reporter: d.sysojew-osinski, Assigned: fchasen)

References

Details

(Whiteboard: [fidefe-Quality-Foundation])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0

Steps to reproduce:

On any page attempt to print website using Ctrl + P

Actual results:

The printing pop-up is displayed with "Preparing Preview", which never completes (left overnight, was still "Preparing Preview")

Expected results:

The printing preview should display and allow printing.

In Browser Console, there is error:

this.availablePrinters[target.printerName] is undefined print.js:1375
get chrome://global/content/print.js:1375
getSettingsToUpdate chrome://global/content/print.js:483
refreshSettings chrome://global/content/print.js:474
AsyncFunctionNext self-hosted:668
(Async: async)
init chrome://global/content/print.js:332
AsyncFunctionNext self-hosted:668
(Async: async)
<anonymous> chrome://global/content/print.js:91
(Async: EventListener.handleEvent)
<anonymous> chrome://global/content/print.js:88

I tried debugging using Browser Toolbox
target.printerName is set to ""
this.availablePrinters is set to:

        Fax: {…}
        "Generic / Text Only": {…}
        "Generic / Text Only (Copy 1)": {…}
        "Microsoft Print to PDF": {…}
        "Microsoft XPS Document Writer": {…}
        "Mozilla Save to PDF": {…}
        "OneNote (Desktop)": {…}
        "OneNote for Windows 10": {…}
        "Splashtop PDF Remote Printer": {…}
        "\\\\fledb1\\dep82_barcode": {…}
        "\\\\fledb1\\dep82_laser3": {…}

Upon further digging it looks like inside resolvePropertiesForPrinter, when running basePrinterInfo.QueryInterface(Ci.nsIPrinterInfo), the defaultSettings.PrinterName is blank, suggesting that the defaultSettings don't come back correctly.

Had a further dig into this, the printer firefox tried to use was "\\fledb1\dep82_laser3", which windows marked as "Printer not found on server, unable to connect". This printer have been disconnected some time ago and as result ceased to exist on the shared print server "\\fledb1".
I suspect that when getting configuration for this printer the settings were not comming back correct and as result was causing a crash.
The crash also causes the printer pop-up to not finish displaying, preventing changing the printer and as result causing catch-22.

Severity: -- → S2
Flags: needinfo?(mstriemer)
Priority: -- → P3
Whiteboard: [fidefe-Quality-Foundation]
Duplicate of this bug: 1800006

Thank you for the detailed report!

So the target in that stack trace should be the this.settings object that we get from the printer [1]. So it seems that somehow we find the printer and get some settings for it, but the printer's name is not included in those settings as it usually is. Setting a breakpoint where we create the proxy object [2], and manually setting this.settings.printerName = "" then continuing does appear to produce the same stack trace.

I would think we might be able to force the printerName on that settings object to match what we expect. Or potentially set the current printer on the proxy when we create rather than looking it up each time from the name.

[1] https://searchfox.org/mozilla-central/rev/dd216c1307a2bf1b0d2465b9749fa86dac44303a/toolkit/components/printing/content/print.js#460
[2] https://searchfox.org/mozilla-central/rev/dd216c1307a2bf1b0d2465b9749fa86dac44303a/toolkit/components/printing/content/print.js#470

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(mstriemer)
Assignee: nobody → fchasen
Status: NEW → ASSIGNED

If the printer info returns without a name, or otherwise errors when checking the settings, it will prevent the print dialog from opening and switching to a different printer.

This wraps the intial refreshSettings call and tries to fallback to another printer if the last used one fails.

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:fchasen, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Flags: needinfo?(mstriemer)
Flags: needinfo?(fchasen)
Pushed by fchasen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/df24b34774f4
Add fallback when getting print settings r=mstriemer
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 110 Branch
Flags: needinfo?(fchasen)
Flags: needinfo?(mstriemer)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: