Closed Bug 1662552 Opened 4 years ago Closed 4 years ago

Print to file from Firefox flatpak works intermittently

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Version:
80 Branch
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
85 Branch
Tracking Flags:
Tracking Status
firefox80 --- wontfix
firefox82 --- wontfix
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- fixed

People

(Reporter: joe_fidler, Assigned: jhorak)

References

(Blocks 1 open bug)

Details

(Whiteboard: [print2020_v85])

Attachments

(1 file)

Bug 1662552 Don't use temp filename in the print dialog when using flatpak; r=stransky
47 bytes, text/x-phabricator-request
Details | Review

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

Steps to reproduce:

Print-to-file from the the flatpak versions of Firefox only intermittently sends output to file name and directory specified in print dialog.

Actual results:

I see this issue on Firefox 79 (Fedora remote) and Firefox 80 (Flathub remote) flatpak versions. Using Flatseal I have enabled permissions for user and host filesystems, and the cups socket. To re-create I bring up the print dialog in Firefox, select a file target (PDF) in my users filesystem - for example in my users downloads folder, and print. This sometimes works as expected, and a PDF with the name given is created in the location selected. However most of the time the output file is sent to the tmp file system of the Firefox container, with a junk filename.

Expected results:

Output PDF file directed to within the app container file system, with a junk filename, instead of users filesystem

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

Component: Untriaged → Printing: Output
Product: Firefox → Core

Host is Linux - Fedora Silverblue 32.

I don't have Fedora to check this for now. cc some other layout people who work on printing now.

Emilio uses Fedora, although I don't think this is related to the printing work we're carrying out right now.

For what it's worth, journalctl does not record any related errors when I print - which maybe true as the print actually completes - but is not directed to the correct location (outside the sandbox) or with correct filename. To keep things simple I just print the google.com page.

[joe@auggie ~]$ flatpak run --verbose --socket=cups --device=all org.mozilla.firefox
F: No installations directory in /etc/flatpak/installations.d. Skipping
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /var/home/joe/.local/share/flatpak
F: Opening user flatpak installation at path /var/home/joe/.local/share/flatpak
F: Opening user flatpak installation at path /var/home/joe/.local/share/flatpak
F: Cleaning up unused container id 154936369
F: Cleaning up unused container id 3828339662
F: Cleaning up unused container id 426597766
F: Allocated instance id 245020354
F: Add defaults in dir /org/mozilla/firefox/
F: Add locks in dir /org/mozilla/firefox/
F: Allowing host-fs access
F: Allowing homedir access
F: Allowing wayland access
F: Allowing x11 access
F: Allowing pulseaudio access
F: Pulseaudio user configuration file '/var/home/joe/.config/pulse/client.conf': Error opening file /var/home/joe/.config/pulse/client.conf: No such file or directory
F: CUPS configuration file '/var/home/joe/.cups/client.conf': Error opening file /var/home/joe/.cups/client.conf: No such file or directory
F: Could not find CUPS server
F: Allowing session-dbus access
F: Allowing system-dbus access
F: Running 'bwrap --args 36 xdg-dbus-proxy --args=38'
F: Running 'bwrap --args 36 firefox'
Gtk-Message: 08:26:35.929: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:35.930: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:36.634: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:36.634: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:37.147: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:37.147: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:37.249: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:37.249: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:38.080: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:26:38.081: Failed to load module "canberra-gtk-module"
[joe@auggie ~]$

[joe@auggie ~]$ journalctl -S -2m

Sep 10 08:55:45 auggie systemd[1528]: Started flatpak-org.mozilla.firefox-68653.scope.
Sep 10 08:55:46 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:46 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:46 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:46 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:46 auggie rtkit-daemon[878]: Failed to look up client: No such file or directory
Sep 10 08:55:46 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:46 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:47 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:47 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:47 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:47 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:48 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:48 auggie rtkit-daemon[878]: Supervising 4 threads of 2 processes of 1 users.
Sep 10 08:55:59 auggie xdg-desktop-por[67166]: evince-previewer not found, disabling print preview
Sep 10 08:56:02 auggie audit: BPF prog-id=145 op=LOAD
Sep 10 08:56:02 auggie audit: BPF prog-id=146 op=LOAD
Sep 10 08:56:02 auggie systemd[1]: Starting Hostname Service...
Sep 10 08:56:02 auggie systemd[1]: Started Hostname Service.
Sep 10 08:56:02 auggie audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd>
Sep 10 08:56:18 auggie systemd[1528]: flatpak-org.mozilla.firefox-68653.scope: Succeeded.
Sep 10 08:56:18 auggie systemd[1528]: flatpak-org.mozilla.firefox-68653.scope: Consumed 15.435s CPU time.
Sep 10 08:56:20 auggie systemd[1528]: Started dbus-:1.2-org.gnome.Nautilus@9.service.
Sep 10 08:56:21 auggie gnome-shell[1659]: libinput error: event17 - Bluetooth 3.0 Mouse: client bug: event processing lagging behind by 14ms, your system is too slow

Severity: -- → S3
Whiteboard: [print2020]

I can see this as well in Fedora Workstation 32 with Wayland session and latest Firefox from flathub. Screenshots are saved properly in the Downloads folder, but printing a file results in the file saved at $HOME/.var/app/org.mozilla.firefox/cache/tmp/ with a "random" filename.

I just found out that the fedora flatpak repository also packages Firefox and I tested it in my Fedora Silverlight VM. The fedora firefox flatpak manages to successfully write webpages when printed as pdf files to the Downloads folder. I noticed that it also creates the same files in $HOME/.var/app/org.mozilla.Firefox/cache/tmp/ with string names (in case that's relevant). Maybe the Mozilla developers can speak with the Fedora maintainers and see how the fedora firefox flatpak is not affected by this bug.

Some information on the versions tested on my machine:

$ flatpak remotes -d
Name    Title   URL                                    Collection ID Filter Priority Options    … … Homepage             Icon
fedora  -       oci+https://registry.fedoraproject.org -             -      1        system,oci … … -                    -
flathub Flathub https://dl.flathub.org/repo/           -             -      1        system     … … https://flathub.org/ https://dl.flathub.org/repo/logo.svg
$ flatpak remote-info fedora org.mozilla.Firefox

Firefox - Web Browser

        ID: org.mozilla.Firefox
       Ref: app/org.mozilla.Firefox/x86_64/stable
      Arch: x86_64
    Branch: stable
   Version: 80.0.1
   License: GPL-3.0+
Collection: 
  Download: 130.3 MB
 Installed: 274.0 MB
   Runtime: org.fedoraproject.Platform/x86_64/f32
       Sdk: org.fedoraproject.Sdk/x86_64/f32

    Commit: 146b4b326761e452926233dc53f4c68b864e61f7bfcaf0bc192a7b6ec963c911
   Subject: Export org.mozilla.Firefox
      Date: 2020-09-03 13:27:53 +0000
$ flatpak info org.mozilla.Firefox

Firefox - Web Browser

          ID: org.mozilla.Firefox
         Ref: app/org.mozilla.Firefox/x86_64/stable
        Arch: x86_64
      Branch: stable
     License: GPL-3.0+
      Origin: fedora
  Collection: 
Installation: system
   Installed: 274.0 MB
     Runtime: org.fedoraproject.Platform/x86_64/f32
         Sdk: org.fedoraproject.Sdk/x86_64/f32

      Commit: 1f331cb3292ba524023f32041f62a65d9c0bb1c8efbcbfd91bab4b69c327eb84
     Subject: Export org.mozilla.Firefox
        Date: 2020-09-03 13:27:53 +0000
      Alt-id: 146b4b326761e452926233dc53f4c68b864e61f7bfcaf0bc192a7b6ec963c911

I just re-tested print-to-file from a web page using the Fedora supplied Flatpak (remote = fedora ) and also see that is now working. When I tested it previously it also failed intermittently.

So I tried using the Flatseal app to change the flatpak/container settings for the mozilla (remote = flathub) version to match those used in the Fedora supplied version. I am going to pretend I knew what I was doing - but in reality I mostly just copied what Fedora had done on their version.

Anyway it looks that if you install a fresh version of the Mozilla / Flathub sourced flatpak and apply the following changes (I used Flatseal) to do this), print-to-file works reliably:

  • add ca.desrt.dconf to the session bus list

  • add DCONF_USER_CONFIG_DIR=.config/dconf to the list of environment variables

An extra copy of each print output is created in my ~/.var/app/org.mozilla.firefox/cache/tmp directory - with a random file name, which is kinda annoying - but a PDF is created in the targeted directory with the correct filename as well.

Good troubleshooting Joe!!

I can confirm that Joe's solutions also works on my machine.

Hi Nikolaos - glad it helped. While the changed flatpak settings have significantly improved reliability for me, I notice I still miss a print-out every now and then.

I have the same issue on Debian 10, with Firefox installed from Flathub. The pdf file used to never be saved to the right location. After applying to the solution suggested by Joe, it works intermittently.

As an update, Firefox version 83.0 of the flathub flatpak still has this issue.

An additional wrinkle I noticed recently is that if you run this flatpak on the Kinoite (KDE based) desktop version of Fedora Silverblue, this issue does not occur.

Assignee: nobody → jhorak

This is where it happens: https://searchfox.org/mozilla-central/source/widget/gtk/nsPrintDialogGTK.cpp#806
The support for the print was done during early stage of flatpak development, this code no longer needs to be there.

Blocks: flatpak

The fallback code is no longer required.

Pushed by malexandru@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fe5358bad29f Don't use temp filename in the print dialog when using flatpak; r=stransky
Pushed by cbrindusan@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/af5961b71885 Don't use temp filename in the print dialog when using flatpak; r=stransky

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

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
status-firefox85: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch

Just tried latest nightly build (85.0a1 ) and print-to-file works great. Thanks for all the work on this - and the new print dialogs look great.

Tried the latest nightly 85.0a1 (non flatpak) and it looks great without and print-to file problems.

Is this worth a Beta uplift? Please nominate if yes :)

status-firefox80: affected → wontfix
status-firefox82: affected → wontfix
status-firefox83: --- → wontfix
status-firefox84: --- → affected
Flags: needinfo?(jhorak)

The patch landed in nightly and beta is affected.
:jhorak, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(jhorak)

Too late for 84 at this point.

status-firefox84: affected → wontfix
Flags: needinfo?(jhorak)
Whiteboard: [print2020] → [print2020_v85]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: