User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:129.0) Gecko/20100101 Firefox/129.0

Steps to reproduce:

In Firefox 129.0.2 (64-bit snap for Ubuntu), opening the Print dialog on any webpage does not result in the ability to print or save to PDF.

With an established profile, in standard mode or launched from the command line with --safe-mode:

1. Go to any webpage
2. Hit ctrl-P to print, or use Menu > Print, or use a JS trigger on the page to open the print dialog.

To attempt debugging this:

• I have made sure my browser is on the latest snap
• I launched Firefox with --safe-mode from the command line
• I went through about:config and deleted all print.printer_ settings
• I rebooted my computer
• I switched the snap's printer interface from core:cups-control to cups:cups-control using the Ubuntu system settings.

Actual results:

The print modal hangs and displays "Preparing Preview" with a spinner. The spinner does not go away after at least 15 minutes. The rest of the modal does not load; there is no option to switch printers or switch to "Print to PDF". The "X" to close the modal does not appear. The only way to dismiss the modal is to press the "escape" key.

Expected results:

I expect that the print preview will render promptly.

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Possibly related: https://bugzilla.mozilla.org/show_bug.cgi?id=1351469

Something in the user profile affects this. I created a new user profile, and Firefox running that profile is able to generate previews without problem.

The presence of the following line in prefs.js in an otherwise-unmodified brand-new user profile causes the described bug:

user_pref("print_printer", "brother");

brother is a reference to one of the printers enabled on this computer, specifically a saved Brother HL-L2350DW series printer with a CUPS driver.

If I remove that printer from the list of saved printers, while keeping the line in the config, then even in the original profile, the print preview renders and the print dialog becomes usable.

Conclusion: Something in the system printer settings can cause the "Print Preview" dialog to hang. Unfortunately, since I have removed that printer setting, it is no longer available for investigation.

If this phenomenon can be reproduced, then the available printers should be listed and examined.

I can reproduce this bug (in both Firefox and Thunderbird). If I clear the print_printer setting via the config editor, the problem goes away, sort of: I can use "print using the system dialog", since switching to the actual printer in the internal dialog causes the button to gray itself out.

Willing to debug more but unsure what to look at. :)

Two questions, since I haven't been able to repro this:

• Would it be possible to take a performance profile with profiler.firefox.com? That should show where time is spent... (I'm guessing we're hanging on somewhere trying to call cups to give us printer info).
• Does this happen on a non-snap build?

(Tentatively blocking snap)

We got other reports specific to snap.

Alex, can you repro this?

no, it works for me

For what it is worth I remember trying to reproduce something related to printing a few months ago on Snap package, that turned out to be some mis-migration somehow. From the reports above it's unclear if it's the Firefox dialog that is at fault or if it's the system dialog one

$ snap connections firefox |grep cups
cups-control            firefox:cups-control             :cups-control                   -

Might be worth trying to disconnect/reconnect that.

that was this: https://bugzilla.mozilla.org/show_bug.cgi?id=1773316 so maybe not related but who knows

This might also be related to https://bugs.launchpad.net/ubuntu/+source/cups-browsed/+bug/2067918 but I'll need to reproduce the issue again to make sure.

This is with the Firefox dialog.

Because the Firefox dialog doesn't load, I can't switch to the system dialog.

I have:

$ snap connections firefox |grep cups
cups-control            firefox:cups-control             :cups-control                   -
cups-control            firefox:cups-control             cups:cups-control               manual

(In reply to ben from comment #4)

The presence of the following line in prefs.js in an otherwise-unmodified brand-new user profile causes the described bug:

user_pref("print_printer", "brother");

brother is a reference to one of the printers enabled on this computer, specifically a saved Brother HL-L2350DW series printer with a CUPS driver.

We've run into similar issues in some other bugs -- bug 1821588 is a case where someone reported 10 minute hangs (on windows). I was able to reproduce a version of the bug, though for me it would only hang for 30 seconds (bug 1821588 comment 14); and it repro'd in (at least) Edge on the same system, too (bug 1821588 comment 15). (That bug is closed as "worksforme" because their 10-minute-hang seems to have been a one-off which stopped happening, so we're unable to investigate further there.)

(AlaskanEmily has talked about removing some of our dependency on cups and just speaking ipp directly, or something along those lines; I think that might conceivably help here, since presumably we're blocked on getting a response from cups. Not sure if we've got a bug filed on that already; if/when we do, it might be worth tying that to this bug with a dependency.)

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.