Closed Bug 1688720 Opened 3 years ago Closed 2 years ago

Use print portal under flatpak

Categories

(Core :: Widget: Gtk, defect, P1)

Product:
Core
Component:
Widget: Gtk
Version:
Firefox 84
Platform:
Desktop
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
90 Branch

People

(Reporter: 5i13ghzt462u, Assigned: jhorak)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Bug 1688720 Use print portal under flatpak because gtk_print_job_new does not work; r=stransky
48 bytes, text/x-phabricator-request
Details | Review

Steps to reproduce

  1. Install the official Linux flatpak of Firefox from Flathub: https://flathub.org/apps/details/org.mozilla.firefox
  2. Go to any website, press Ctrl+P/select to print.
  3. It now opens the system dialog for printing (likely because it uses a portal or so it cannot show Firefox's own dialog)
  4. Choose "Print".

You see a progress bar as usual (it is quite fast, but sending a printing job may be fast). You also see a notification about a finished printing job.
However, it does not print it. Also no print job is shown in the printer settings.

What does work, however, is everything else: If I print something else, it even shows the current state in the printing dialog – maybe, because that's just a system component.

System

Firefox 84.0.2
Fedora 33 Silverblue
GNOME here
Reproduced with:

  • two different systems (devices)
  • two different printers (Canon and HP)
  • two different printer connections (USB, WiFi)

When I print the website into a PDF file (which works in the dialog) and then use another app (Evince e.g.) to print the PDF, it does work, however. So it's not a system error.
Also, in the non-Flatpak versions it also seems to work.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Blocks: flatpak
Priority: -- → P3

I believe I am also seeing this in the Firefox 86.0 Flatpak. All print jobs created using either the Firefox internal or system print dialogs vanish when sent to a physical printer and don't appear in CUPS queue at all. Print-to-file (PDF) is OK. Printing works from non-flatpak Firefox 86.0 and other apps to the same destination printer, on same desktop.

I have reset printer settings and have also set cups=socket for the Flatpak. Desktop is Fedora Silverblue 33.

I can reproduce it only by using Firefox's printing dialog, I have no such issue on Firefox 88.0.1 for flatpak

Can you print by selecting "Print using system dialog window" or by setting "print.tab_modal.enabled" in about:config to false?

Firefox is using the gtk_print_job_new to fire the printing. This does not work under Flatpak, I'll check which options we have with the portals.

Assignee: nobody → jhorak

Under flatpak when the 'print.tab_modal.enabled' is set (default now) the print use gtk_print_job_new
which doesn't work under flatpak. We need to use "Print" portal for the task.

Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/a198c10bae42
Use print portal under flatpak because gtk_print_job_new does not work; r=stransky

https://hg.mozilla.org/mozilla-central/rev/a198c10bae42

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox90: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch

Upstream bug regarding Print method: https://github.com/flatpak/xdg-desktop-portal/issues/585

QA Whiteboard: [qa-90b-p2]

5 month later, and it still doesn't work for me ...

My flatpak is fully updated (At least my Mint 20.2 says so. flatpak version 1.6.5, Thunderbird version 91.2.0, flatpak update says "Nothing to do")
In Flatseal: Thunderbird->PrintingSystem is enabled.

Still, on both dialogs (internal dialog as well as system printing dialog),
no content arrives at my printer (which is a Samsung network printer)

Can anyone enlighten me ?

Hi @pahhur - I just tested this (again) and see the same issue when printing to a physical printer (print-to-file does work).

The Firefox internal print dialog runs OK, but the print jobs disappear - much like the original bug described above. Same if I print using the system print dialog. No errors are reported, the print jobs are not seen in the CUPS queue, and no errors reported. Other Flatpak apps can use same CUPS queues successfully.

I saw this on both Firefox and Thunderbird:
Firefox (93.0 Flathub Flatpak): printing a web page to real printer fails.
Thunderbird (91.2.0 Flathub Flatpak) : print an email to real printer fails.

For both:
Printing system (socket=CUPS) enabled for both (Flatseal)

I am confused, I think this open bug https://github.com/flatpak/xdg-desktop-portal/issues/585 mentions the bug here as upstream, but this one is closed. Like I said I am probably confused - time for a nap.

I'm confused too!
The bug has been closed but the problem persists. Did I miss something? How to fix?
Debian 11, Gnome 3.38, Flatpak, Firefox 94

Yes, you're right, i just doesn't work.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → NEW
Priority: P3 → P1

Firefox 95 on PopOs 21.10 is still affected by the bug.

Regressions: 1746559

It's Feb 9th, 2022 now (another 4 months later), I'm now on arch, having both

  • a freshly updated system (via pacman), and
  • a fully updated flatpak (via flatpak update)

The versions are as follows

Thunderbird 91.5.1
Kernel 5.16.7
flatpak 1.12.4
flatseal 1.7.5

and the problem persists.

Can anyone of the persons in charge tell us, when this issue will be fixed, starting maybe with the explanation why there is a problem at all?

flatpak is literally unusable, if applications like Thunderbird or Firefox cannot print ...

I have already given up using the flatpaks of thunderbird and firefox because of that printing issue! Fortunately the versions shipped for firefox and thunderbird by almost all Linux distributions are basically up-to-date (with usually only a delay of maximum few days compared to flathub). So there is actually no real benefit in replacing the distribution specific packages for those apps by the corresponding flatpaks. ;-)
Apart from these two mozilla flatpaks, I have never experienced any printing problems with any of the other flatpaks distributed by flathub, e.g. libreoffice, evince, eog, which I'm regularly using.

At least there was a workaround for this - to set print.tab_modal.enabled to false. Unfortunately the setting is now ignored (https://bugzilla.mozilla.org/show_bug.cgi?id=1754630) and now printing on Flatpak is completely broken

(In reply to thanosz from comment #18)

At least there was a workaround for this - to set print.tab_modal.enabled to false. Unfortunately the setting is now ignored (https://bugzilla.mozilla.org/show_bug.cgi?id=1754630) and now printing on Flatpak is completely broken

Yesterday I tested the snap versions of firefox and thunderbird (which are also running in a "sandbox"). They can print with no problems with either printer dialogue! It's somewhat ridiculous that the flatpak versions can't. I would not argue much about if that problem existed only since few weeks, but it's more than a year old by now. This suggests to me that the corresponding flatpak packers don't really care if basic features of their packages are broken, making both the packages and the related work useless to the bottom line.

(In reply to jak207 from comment #19)

(In reply to thanosz from comment #18)

At least there was a workaround for this - to set print.tab_modal.enabled to false. Unfortunately the setting is now ignored (https://bugzilla.mozilla.org/show_bug.cgi?id=1754630) and now printing on Flatpak is completely broken

Yesterday I tested the snap versions of firefox and thunderbird (which are also running in a "sandbox"). They can print with no problems with either printer dialogue! It's somewhat ridiculous that the flatpak versions can't. I would not argue much about if that problem existed only since few weeks, but it's more than a year old by now. This suggests to me that the corresponding flatpak packers don't really care if basic features of their packages are broken, making both the packages and the related work useless to the bottom line.

We're just missing manpower here.

Jan, any idea here?

Flags: needinfo?(jhorak)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #20)

(In reply to jak207 from comment #19)

(In reply to thanosz from comment #18)

At least there was a workaround for this - to set print.tab_modal.enabled to false. Unfortunately the setting is now ignored (https://bugzilla.mozilla.org/show_bug.cgi?id=1754630) and now printing on Flatpak is completely broken

Yesterday I tested the snap versions of firefox and thunderbird (which are also running in a "sandbox"). They can print with no problems with either printer dialogue! It's somewhat ridiculous that the flatpak versions can't. I would not argue much about if that problem existed only since few weeks, but it's more than a year old by now. This suggests to me that the corresponding flatpak packers don't really care if basic features of their packages are broken, making both the packages and the related work useless to the bottom line.

We're just missing manpower here.

Please don't misunderstand me! I very much appreciate the work being done by the various flatpak packers. But whenever resources are limited, it is even more important to rethink priorities. In such a situation, I think it would be a good idea not to repackage every single frequent (minor) update of those Mozilla applications within a relatively short period of time (as it is the case now), but to focus more on the quality of these flatpak packages. I am convinced that the majority of users would greatly appreciate such a revised "strategy".

(In reply to jak207 from comment #22)

Please don't misunderstand me! I very much appreciate the work being done by the various flatpak packers. But whenever resources are limited, it is even more important to rethink priorities. In such a situation, I think it would be a good idea not to repackage every single frequent (minor) update of those Mozilla applications within a relatively short period of time (as it is the case now), but to focus more on the quality of these flatpak packages. I am convinced that the majority of users would greatly appreciate such a revised "strategy".

The 'repackage' is done automatically without any user interaction.

Also no the "majority" of users would not like to get delayed updates, because at least I want to have security fixes as soon as they are published and not have a vulnerable Firefox instance.
This bug is unfortunate sure and I am also desperately waiting for it to be resolved but well… that's how it is.

We're working on it in the bug 1712555.

Most updates do not contain security-related fixes. So it would be better to fix the basic problems like the one discussed here than to provide a new version with minor functional enhancements or other fixes. Of course, security-related updates should have a higher priority.
On the other hand, if an application lacks basic features, the number of people using the application will drastically decrease. Consequently, at some point, even security related fixes / updates will become irrelevant then. ;-)

(In reply to jak207 from comment #26)

Most updates do not contain security-related fixes. So it would be better to fix the basic problems like the one discussed here than to provide a new version with minor functional enhancements or other fixes. Of course, security-related updates should have a higher priority.
On the other hand, if an application lacks basic features, the number of people using the application will drastically decrease. Consequently, at some point, even security related fixes / updates will become irrelevant then. ;-)

(In reply to rugk from comment #24)

Also no the "majority" of users would not like to get delayed updates, because at least I want to have security fixes as soon as they are published and not have a vulnerable Firefox instance.
This bug is unfortunate sure and I am also desperately waiting for it to be resolved but well… that's how it is.

Most updates do not contain security-related fixes. So it would be better to fix the basic problems like the one discussed here than to provide a new version with minor functional enhancements or other fixes. Of course, security-related updates should have a higher priority.
On the other hand, if an application lacks basic features, the number of people using the application will drastically decrease. Consequently, at some point, even security related fixes / updates will become irrelevant then. ;-)

All Firefox updates contain security fixes, gave a look at the release notes so for Firefox you should get them as soon as possible. Also this is oggtopic anyway so let's stop this discussion here but one more point: Of course features are implemented by others than who package flatpaks and that flatpaks team may be small and while that is a decision that can be changed, let's not blame that team for not being good enough.

This also seems to effect non-flatpack use of XDG-Desktop-portal, since I find the latest GTK-file-picker to be very annoying for my workflows, and since I need to print off shipping labels regularly for my small business...

Well this is a very annoying bug for me personally, not quite enough to make me move to chrome, but close.

(In reply to traverse.da from comment #29)

This also seems to effect non-flatpack use of XDG-Desktop-portal, since I find the latest GTK-file-picker to be very annoying for my workflows, and since I need to print off shipping labels regularly for my small business...

Well this is a very annoying bug for me personally, not quite enough to make me move to chrome, but close.

Simply use any other firefox package aside from the flatpak one, i.e. either an rpm / deb suitable for the distribution you're using or the snap package. Printing will work no matter which decision you're going to make! ;-)

Simply use any other firefox package aside from the flatpak one, i.e. either an rpm / deb suitable for the distribution you're using or the snap package. Printing will work no matter which decision you're going to make! ;-)

No? If you use about:config to enable XDG-dektop-portal on your distro-provided firefox this bug is still present, at least it is using XDG-desktop-portal-kde. I'm using firefox 97.0.

That should be fixed in 97 since there are multiple prefs now? See bug 1746559.

No longer blocks: flatpak
Status: NEW → RESOLVED
Closed: 3 years ago → 2 years ago
status-firefox90: affected → ---
No longer regressions: 1746559
Resolution: --- → DUPLICATE
Target Milestone: 90 Branch → ---

This should be fixed by bug 1712555 in Firefox 99.

I was going to mark this as a duplicate, but there was code specific to this bug that landed in comment 8. I'll rename this to show what was landed here.

Blocks: 1712555
Regressions: 1746559
Resolution: DUPLICATE → FIXED
Summary: Printing does not work in flatpak version → Use print portal under flatpak
Target Milestone: --- → 90 Branch
Blocks: flatpak

This should be fixed by bug 1712555 in Firefox 99.

ok, and what about Thunderbird?

It is not working in firefox 99 flatpak, ubuntu 22.04 xorg session. I have reported this in bug 1712555
The problem I have is exactly as reported. No printers are visible in either the print dialog or the "print from system dialog". Can only save a pdf.
flatseal shows that cups service is enabled.

it is not a problem with my system: the snap (beta) works fine.

Hm, I just freshly installed the Ubuntu 22.04 in virtual machine and I see all the printers in the org.mozilla.firefox 99 flatpak. Please check the output of following commands

flatpak run --command=sh  org.mozilla.firefox
ls -l /app/lib/gtkmodules/3.0.0/printbackends
cat /app/etc/xdg/gtk-3.0/settings.ini
Flags: needinfo?(jhorak)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: