1707454 - Print tab modal preview loading forever

Status: RESOLVED WORKSFORME

(Toolkit :: Printing, defect)

Description

[Michel Le Bihan]

Hello,

I noticed that the new print preview modal is taking forever (it didn't generate even after waiting for a very long time) to generate on Windows, but it's instant on Linux.

It happens on any website, but let's use https://staszic.waw.pl/ as an example.
Steps to reproduce:

1. Make sure that print.tab_modal.enabled is set to true
2. Press Ctrl + P
3. See Preparing Preview loading forever

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Print Preview' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Tom S [:evilpie]]

Did you disable the printer spooler service?

Comment 4

[Michel Le Bihan]

I did not disable it and I see that the service is running. Is there a way to check if it's working correctly?

Comment 5

[Tom S [:evilpie]]

Not that I am aware. Maybe post you about:support information here. You can also try "Clear saved print settings" on the same page, but I doubt it will help.

Comment 6

[Michel Le Bihan]

Attachment: about_support.json

Comment 7

[Daniel Holbert [:dholbert]]

Could you use the Firefox Profiler to capture a performance-profile of this happening?

To do that:
(1) Ideally, close all of your tabs to reduce the amount of data that the profiler is dealing with (and the amount of data you're publishing via capturing a profile). (Alternately, create a new browser user-profile at about:profiles and perform the following steps in that user-profile.)

(2) Visit https://profiler.firefox.com/ and click the button on the website to enable Firefox's performance-profile toolbar button (which looks like a speedometer once you've enabled it)

(3) Click the dropdown arrow next to the profiler toolbar-button and choose "Settings: Firefox Platform"

(4) Click the toolbar icon to start capturing a performance profile.

(5) Start a print operation that hangs.

(6) After a minute or two (giving it plenty of time to let any pending requests/etc. time out), click the toolbar icon again to capture the performance profile (which will open a visualizer UI)

(7) In the visualizer, click "Upload local profile" at the top right. After the profile uploads, it'll give you a short URL. Paste that here.

Thanks!

Comment 8

[Michel Le Bihan]

https://share.firefox.dev/3uoaQTC

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I think the print preview just failed somehow. Does going to about:support and clicking "clear saved print settings" help?

Comment 10

[Daniel Holbert [:dholbert]]

Alternately/also: do any new logging statements get added to the browser console (Ctrl+Shift+J), around the moment where you start the print operation?

I wonder if there's some JS exception being thrown during the construction of that view (which would hopefully show up in the browser console)...

Comment 11

[Michel Le Bihan]

Yes, there is. Sorry, I messed it when reporting the bug.

Comment 12

[Michel Le Bihan]

Attachment: Screenshot__3_.png

Comment 13

[Michel Le Bihan]

I enabled print.debug and saved the output on the console. Then I removed that default printer form printers and devices. Now print preview loads instantly. There is something about that printer that FF doesn't like.

Comment 14

[Michel Le Bihan]

Attachment: console-export-2021-5-7_15-12-31.txt

Comment 15

[Daniel Holbert [:dholbert]]

Thanks, Michel. I'll copypaste most of that output here for searchability/discoverability, since it's not too verbose:

printUI: availablePrinters:  
Array(7) [ "Mozilla Save to PDF", "OneNote for Windows 10", "OneNote (Desktop)", "Microsoft Print to PDF", "HP655022 (HP Officejet Pro 8610)", "HP LaserJet Professional P1606dn", "Fax" ]
print.js:244
printUI: defaultSystemPrinter:  
Object { name: "HP655022 (HP Officejet Pro 8610)", value: "HP655022 (HP Officejet Pro 8610)" }
print.js:245
printUI: Printer has empty paperList:  undefined using fallbackPaperList print.js:1228
printUI: currentPrinter name:  HP655022 (HP Officejet Pro 8610) print.js:475
printUI: settings: 
Object { printToFile: false, isInitializedFromPrinter: true, toFileName: "", paperSizeUnit: 0, printSelectionOnly: false, edgeTop: 0, edgeLeft: 0, edgeBottom: 0, edgeRight: 0, marginTop: 0.5, … }
print.js:476
Uncaught (in promise) TypeError: can't access property "supportsColor", this.availablePrinters[target.printerName] is undefined
    get chrome://global/content/print.js:1377
    getSettingsToUpdate chrome://global/content/print.js:490
    refreshSettings chrome://global/content/print.js:481
print.js:1377:9

So this was print.js getting confused because this.availablePrinters[target.printerName] was undefined for some reason, I think for your printer HP655022 (HP Officejet Pro 8610), which is your system default.

sfoster, do you know what might be going wrong here?

For reference, the line of code in question (where the exception is being thrown) is here:

  get(target, name) {
[...]
      case "supportsColor":
        return this.availablePrinters[target.printerName].supportsColor;

https://searchfox.org/mozilla-central/rev/a8773ba2a8f015e0525f219a7e55087b04d30258/toolkit/components/printing/content/print.js#1377

Comment 16

[Sam Foster [:sfoster] (he/him)]

There's a couple fishy things going on there. The Printer has empty paperList: undefined line is unexpected. Yes, we handle this by using the fallbackPaperList, but its a red flag that no paperList was available for this printer at this point. That fallback support is for virtual printers which we don't expect to supply a sane paperList. Is it possible other properties/functions of this printer failed to initialize and the paperList just happens to be the one we have debug logging for?

Also, the stack shows that we're in the middle of switching print destination, from one printer to another. Or perhaps this is the initial setup and there was no current printer yet? It would be good to know what target.printerName is at that point - target is our settings object. The debug logging does output the serialized settings, but its been elided in the log here (Probably that log statement should JSON.stringify it first.) It should be "HP655022 (HP Officejet Pro 8610)".

That doesnt really point at a solution.. Maybe we/I could expand on the logging and get a build this user could try out? I'm just guessing with the information we have here.

Comment 17

[Sam Foster [:sfoster] (he/him)]

Michel, recent Nightlies should now have better logging for the print UI. Would you be able to repeat the steps you used for Comment 14? The log should now include the full details of the print settings, including what we think the current printer name is - which I hope will give us some leads to go on here. There is also logging of the defaultSystemPrinter. If you spot that in the console it will be collapsed with a > to expand the object. Can you let me know what the expanded object looks like? It should have details about the paperList, supportsColor etc. and I would be interested to know if any of those properties have values that aren't undefined.

Comment 18

[Michel Le Bihan]

Hello,
I can't reproduce the issue anymore. Do you still want the debug output?

Comment 19

[Sam Foster [:sfoster] (he/him)]

(In reply to Michel Le Bihan from comment #18)

Hello,
I can't reproduce the issue anymore. Do you still want the debug output?

Thanks, no its just the error case that the debug output would be useful for. Well I'm glad that resolved itself, if it does crop up again, please let us know.

Comment 20

[souleye]

I have the same issue. It arises in Thunderbird for me. I am completely new to this platform. This is the only place on the internet where my issue is described. Would love some help on the subject and instructions on what to do.

Comment 21

[Daniel Holbert [:dholbert]]

It's likely worth starting out with a new bug, rather than resurrecting this one. (It may superficially sound like you're hitting the same issue, but it's quite likely to be different; there are all sorts of different things that can cause similar breakage with printing.)

Could you fill out the form at https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&component=Printing to file a new bug? Be sure to mention your Thunderbird version and OS details, and whether this just started happening recently, and whether it happens with every email vs. only certain ones. Once you've filed that bug, feel free to post a comment with a link to your new bug here.

Thanks!