Bug 192748 – [GTK] Printing does not work when running inside Flatpak

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Adrian Perez]

SSIA.

[Adrian Perez]

Related: https://bugs.webkit.org/show_bug.cgi?id=79226#c8

[Michael Gratton]

Dupe: https://gitlab.gnome.org/GNOME/geary/issues/348

[Michael Catanzaro]

It has mysteriously begun to work for me....

[Michael Gratton]

Per https://github.com/flathub/org.gnome.Geary/issues/42 a workaround for this is adding explicit RW access to `~/Downloads` or similar, so at least people can print to PDF and print that using Evince or whatever.

[Michael Catanzaro]

Let's track this in bug #202363.

*** This bug has been marked as a duplicate of bug 202363 ***

[Michael Catanzaro]

Reopening since bug #202363 was resolved without fixing flatpak.

[Michael Catanzaro]

*** Bug 244332 has been marked as a duplicate of this bug. ***

[Milan Crha]

I can "Print to file" under Flatpak, but the file chooser does not let me pick host-system directories, while running the same dialog as gtk3 wants makes it work properly. Steps, in Evolution:

1) go to the Mail view and select a mail message
2) press Ctrl+P and there select "Print to File"
3) click the button with the file name, file chooser dialog opens

Actual Result:
No host-system directories shown

Expected:
Host-system directories are shown

4) go to the Contacts view and select a contact there
5) press Ctrl+P  and there select "Print to File"
6) click the button with the file name, file chooser dialog opens

Actual and Expected Result:
Host-system directories are shown

That makes me believe something in the WebKitGTK is broken, even though the GtkPrintUnixDialog is used in the both above cases.

One thing to note, at least to what I see, the gtk+ uses GtkFileChooserDialog for here, while it may rather use GtkFileChooserNative, to work under Flatpak sandbox, I guess. It's weird to see bad and then correct directories in the dialog. I mean, I'd say the problem is on the gtk3 side, but if calling the dialog in the evo process works, then the problem is possibly somewhere in the WebKitGTK.

Does the WebKitGTK's print dialog run in the WebKitWebProcess, thus possibly under the WebKitGTK's own sandbox?

[Georges Basile Stavracas Neto]

Pull request: https://github.com/WebKit/WebKit/pull/26765

[EWS]

Committed 277671@main (fd47d132791d): <https://commits.webkit.org/277671@main>

Reviewed commits have been landed. Closing PR #26765 and removing active labels.