1978214 - print hangs on linux

Status: UNCONFIRMED

(Core :: Printing: Output, defect)

Description

[cherkah]

Attachment: thunderbird_crash.txt

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

Steps to reproduce:

With the tarballs version of Thunderbird 140, it's impossible to print: the printwindow appears blank with the wheel spinning indefinitely. It's possible to close the module with 'escape'. However, this doesn't close the module.

Actual results:

If you try to close Thunderbird, 3-5 seconds later, you get the crash reporter.
This only happens if the print module is called.
I'm using Fedora 42 and all the libraries are installed on my system.
see the crash-report file

Expected results:

i would like to be able to print on thunderbird (printer/pfd).

Comment 1

[Corey Bryant]

This works for me on my end with 141.0b4 on Ubuntu 24.04 installed with tarballs from thunderbird.net

Comment 2

[cherkah]

so i have to wait for the 141.XX

Comment 3

[Corey Bryant]

Maybe.. let us know if it is fixed there for you.

Comment 4

[cherkah]

Attachment: bug thunderbird

Comment 5

[cherkah]

Attachment: bug firefox

Comment 6

[cherkah]

Attachment: bug thunderbird

Comment 7

[cherkah]

Attachment: bug thunderbird

Comment 8

[cherkah]

ok so i just updated thunderbird/firefox to version 141 today.

the problem is still the same for both programs and the generated bugslogs give the same information. on my fedora 42 kde, my printing system works normally (cups, cups-pfd installed) and the libreoffice interface works.

even if thunderbird was installed via the thunderbird.net tarballs, firefox installed via dnf5 should not fail in the presentation. i made 2 screen recordings to illustrate the problem. i will broaden the field of investigation

Comment 9

[Corey Bryant]

Both of your attachments are firefox. Regardless, since thunderbird is built on top of firefox I'm going to move this bug to firefox.

Comment 10

[cherkah]

Attachment: bug thunderbird

Comment 11

[cherkah]

ok thanks.
PS: the version for both is 141 and i 've updated the thunderbird's record

Comment 12

[BugBot [:suhaib / :marco]]

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.

Comment 13

[Jonathan Kew [:jfkthame]]

This doesn't reproduce on my Linux machine. We need to try and figure out why it's getting "stuck" for you but not for others.

Please try the following to collect a profile that might give us a clue what's happening:

• Load a PDF file that reproduces the problem in a browser tab, and click the Print button
• In another tab, go to about:processes, which shows a list of the various Firefox processes that are running
• Identify which one is the process displaying your PDF (if you've loaded a local PDF file, I think the process name will be "Files", and then it'll list the actual tab title etc underneath this)
• Notice that when you hover the mouse over the process name, a "speedometer dial" icon appears beside it -- this is a button to capture a profile of what the process is doing
• Click that Profile button for the process that's displaying the PDF (and trying, unsuccessfully, to display the print preview)
• Wait several seconds while the profile is captured; when ready, it will open in a new tab
• In that profile tab, click the Upload Local Profile button (at the top right) to store the profile where we can examine it
• That will give you a link to the uploaded profile; paste it into a new comment here

Once the profile has been uploaded (and the link recorded here), you can close the various tabs; I assume the PDF tab will still just be showing its "forever spinner".

With luck, the profile may help us identify what kind of problem may be happening.

Comment 14

[cherkah]

Okay, I solved the problem last night:

1. Firefox/Thunderbird: about:support : Print > erase settings ...
2. Terminal: rm -rf /var/lib/cups /var/spool/cups
3. Firefox: **about:config **: print.prefer_system_dialog -> tru****e
4. Reboot system

Now I'm using the dialog_system and it's consistent.

I have no idea what the problem is, and it's strange that it's happening on an up-to-date system (Fedora 42 + KDE + Wayland + NVIDIA + dual monitors...).

Comment 15

[cherkah]

ok there is the link:
https://share.firefox.dev/44PdwOQ

I assume the PDF tab will still just be showing its "forever spinner".
correct

ps: if Firefox: **about:config **: print.prefer_system_dialog -> false ; then the issue comes back

Comment 16

[Jonathan Kew [:jfkthame]]

I'm glad you have found a way to work around the problem. We'd still like to figure out what's going wrong with print.prefer_system_dialog = false, though, as this may indicate a bug that could affect other users as well.

If you're able to try the steps described in comment 13 above, to create a profile when the problem happens, that would be really helpful. Thank you!

Comment 17

[cherkah]

i've already provide the profile. just take a look to my Comment 15 so as to get all informations you need

Comment 18

[Jonathan Kew [:jfkthame]]

Oh, I'm sorry, I missed that - I was just paying attention to the fact that you found a workaround. Thank you!

Comment 19

[Jonathan Kew [:jfkthame]]

Hmm - that seems a bit surprising; there's not as much information there as I'd hoped. The web-content process seems to be just waiting for some kind of event, and not getting it.

Could you please repeat this, but this time capture a profile of the main Firefox process (I think it'll be the first one in the about:processes list)? I wonder if that main process is somehow "stuck". Thanks again!

Comment 20

[cherkah]

ok hier it is:
https://share.firefox.dev/4lMGFQq

Comment 21

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:dshin, could you have a look please?

For more information, please visit BugBot documentation.

Comment 22

[Daniel Holbert [:dholbert]]

This sounds a lot like bug 1980356 (issue with printing PDFs, starting in 140, with print.prefer_system_dialog being relevant).

However, bug 1980356 specifically reproduces when print.prefer_system_dialog is set to true, whereas it looks like this bug here reproduces when that pref is set to false.

One other diagnostic that would be useful to try... Could you go to about:config and set the preference print_printer to the string...

Mozilla Save to PDF

...and see if that helps at all? (for the next print operation)

(That pref gets overwritten on each print operation -- it just stores the most-recently-used printer, which will then come up as the default for your next print operation. If setting it to the save-to-PDF printer helps, then that lets us know that the the hang might be specific to Firefox waiting on printer information from whatever other printer would get used as your default, which is handy to know.)

Comment 23

[cherkah]

1. print.prefer_system_dialog (true) + print_printer (Mozilla Save to PDF) -->> i can print to PDF but not with cups-pdf & my printer

2. print.prefer_system_dialog (false) + print_printer (Mozilla Save to PDF) -->> i can print to PDF but not with cups-pdf & my printer

I also reinstalled cups and other packages related to printing and reconfigured the printing system to eliminate the hypothesis of externality of the bug. But nothing works. Even cleaning the cache...

Comment 24

[Daniel Holbert [:dholbert]]

Thanks. So: given that this doesn't reproduce with our built-in PDF printer, this must be related to Firefox/CUPS communication in some way.

(not saying CUPS itself is at-fault; it just appears to be specific to the flow when we're getting ready to print or print-preview to a printer that we discover/communicate-with via CUPS.)

One other clarification: you mentioned PDF in the bug title, but does this affect other content as well? (i.e. under an affected configuration, can you e.g. print http://example.org/ ?)

Comment 25

[cherkah]

".... you mentioned PDF in the bug title, but does this affect other content as well?"
You are right, I should say that printing is not possible regardless of the type of file to be printed: .pdf, .txt, .py...

Comment 26

[Daniel Holbert [:dholbert]]

OK, thanks for clarifying. (That helps to confirm that this is unrelated to bug 1980356; removing see-also for that one.)

Right now we're unable to reproduce which makes it a bit hard to proceed/investigate; but this does seem to be a instance of a rare issue that users occasionally hit and then mysteriously goes away (see e.g. bug 1931049 [EDIT: fixed bug link, I copypasted the wrong one at first]). I don't have concrete suggestions at the moment (aside from the workaround that you already discovered), but if you're able to discover anything else on your end (additional factors/workarounds), please feel free to add more notes here and they might prove useful for later reproducing/investigating.

Comment 27

[cherkah]

Nota bene: no probleme to print with libreoffice, kde plasma softwares ...