I have the flatpak for Firefox installed and I get the printer dialog which pops up to select my printer. But when I click okay and try to print it just puts the rendered file in /home/username/.var/app/org.mozilla.firefox/cache/tmp/gtkprint{random} and doesn’t actually print it. I was wondering if anyone else has this problem, I was thinking it was a portal issue but that seems to be fine as the gtk pritner selection screen comes up and I can see my printers.
I would like to be able to print directly from my flatpak installed firefox instead of having to take two to three steps to get a print job.
Any suggestions on how to troubleshoot or fix this would be great. I’m pretty new to flatpaks.
@barthalion – I am having the identical problem printing from Firefox 79.0/Flatpak 1.0 as Rich, and accumulating …cache/tmp/gtkprint* files just as he described. Attempting to Print To File (PDF) also defaults to saving the PDF in the …cache/tmp/ folder as well (but that, at least, can be changed to, say, ~/Downloads.) I require the Firefox 79.0 flatpak because version 68.11 currently available in the Debian repos does not support Zoom for job interviews. (I am a COVID-19 casualty.)
Printing seems to proceed normally, except the printer never sees the jobs (“No active jobs.”) Removing the printer and re-detecting and adding it back to the devices list has no effect.
In answer to your question, yes, I have the following xdg support modules installed.
~$ sudo apt list xdg-* | grep installed
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
xdg-dbus-proxy/stable,now 0.1.1-1 amd64 [installed,automatic]
xdg-desktop-portal-gtk/stable,now 1.2.0-1 amd64 [installed,automatic]
xdg-desktop-portal/stable,now 1.2.0-1 amd64 [installed,automatic]
xdg-user-dirs-gtk/stable,now 0.10-3 amd64 [installed]
xdg-user-dirs/stable,now 0.17-2 amd64 [installed,automatic]
xdg-utils/stable,now 1.1.3-1+deb10u1 all [installed,automatic]
If you can provide instructions for getting diagnostic information, I will be happy to comply.
:~$ lsb_release -ds ; uname -srm ; gnome-shell --version ; echo $XDG_SESSION_TYPE
Debian GNU/Linux 10 (buster)
Linux 4.19.0-10-amd64 x86_64
GNOME Shell 3.30.2
wayland
I will double check this but I believe that I have them installed. Sorry I didn’t see this show up in my notifications.
I thought I had fixed this by changing the type of printer I was using from ppd to a new format. But that worked till I rebooted my computer. Once my computer rebooted, I was back to square one with the print jobs just going back into the Firefox tmp folder in my user.
Same as @rtimai I would be happy to do any troubleshooting.
I’m not using Firefox for printing, but if you’ve Flatseal installed, you can see that Firefox flatpak doesn’t have access to CUPS service by default. You haven’t mentioned allowing CUPS access so that might be something you might need to check.
I have since removed Firefox 79.0 flatpak, but no, I was using “HP Deskjet 1110 Series hpijs-ppds 3.18.12” (for Deskjet-1112) at localhost with a USB connector, which is the automatically selected driver. CUPS is installed by default in Debian 10, but the CUPS driver is not selected. I do think this may be a xdg-desktop issue, as I have seen other posts describing printing fails from other flatpak applications as well.
I’ve just experienced this issue, I think what’s happening is that because Firefox has a custom print dialog box, it’s bypassing the print portal. When I select “Print with system dialog…” then printing works. I think this means that if Firefox wants a custom print UI, it needs to explicitly detect Flatpak and use the portal when appropriate.
Printing from the mozilla flatpak apps, i.e. not only firefox but also thunderbird, still is an unresolved issue - at least for me.
I am using CentOS Stream 8, on which I have installed several important desktop applications (e.g. LibreOffice, Evince, Eye of Gnome, etc.) also as flatpaks, in addition to the two Mozilla applications mentioned above. Except for the mozilla apps, printing works fine with all of them. Printing did also work fine with the CentOS specific rpm packages of firefox and thunderbird that I had installed in the past. That’s why I suspect the root cause of the print problems with the firefox and thunderbird flatpaks in their build process or within their runtime environment or maybe just an environment variable that needs to be set properly.
Originally, I suspected insufficient system access rights as the cause of the problem. However, the problem was not solved even after I had given the applications all possible permissions listed by Flatseal…
Regardless of whether I use the built-in print dialog of those apps or select the corresponding system print dialog from within the apps’ print dialog, there is no print job being queued even though the corresponding printer device does correctly appear in the dialog. The only working but quite cumbersome solution I have found so far is to store the pages to be printed to a PDF and then open this PDF from the file system with e.g. evince just for the purpose of printing.
Do you have any ideas? Thank’s in advance!
I recently installed FF Flatpak on Debian 12.5 and discovered this issue.
I have now resolved it by also installing Flatseal.
Select Firefox from the left pane and set switch ON for D-Bus session bus. This will allow installed system printers in Firefox to be seen by PDFs &etc listed in the dialogue drop down box.
UPDATE 29 May 2024
A month in since I changed the settings in Flatseal (see prior post) and the issue has re-emerged.
Fixed it again by recycling the D-Bus settings in Flatseal (Firefox application) adding in D-Bus system bus this time but still no fix until FF was closed then re-started then it performed as required.
Has anyone managed to find a persistent fix for this long outstanding issue or should I just abandon the Flatpak version and run with the .deb version instead link here or are there other settings to try I have missed?
