Bug 202363 – [GTK] Printing not working with bubblewrap sandbox enabled

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Master One]

This bug was originally posted as https://gitlab.gnome.org/GNOME/epiphany/issues/957 but I was advised to put this here.

On a fresh installation of Arch Linux with Gnome 3.34.0 I can not make Epiphany to print anything. Printers are setup correctly and work from other applications. I have attached 3 screenshots:

When I press Ctrl-p or select printing from the menu, the Gnome print dialog comes up as expected.

https://gitlab.gnome.org/GNOME/epiphany/uploads/9265d127fad8c3afccaa0c4ec56d027c/epiphany_print1.png

When I select a printer (in my case "netbrother" or PDF) and click Print, the print dialog disappears and the error message "Printer not found" is shown.

https://gitlab.gnome.org/GNOME/epiphany/uploads/319edb378b6dda5bd1598c5d9d331231/epiphany_print2.png

When I select "Print to File" and click Print, the print dialog disappears and the error "No such file or directory" is shown.

https://gitlab.gnome.org/GNOME/epiphany/uploads/d5e6f967b493abe1778ac5c4e4f61bac/epiphany_print3.png

[Carlos Garcia Campos]

Does this happen with sandboxing disabled?

[Michael Catanzaro]

It works with WEBKIT_FORCE_SANDBOX=0, so I guess it's trying to print from the web process? That's weird.

Would be good to fix bug #192748 at the same time. Switching WebKitPrintOperation to use either GtkPrintOperation or the printing portal directly should suffice for both bugs.

[Carlos Garcia Campos]

The dialog runs in the UI process, and the generated settings are sent to the web process. In the web process we use GtkPrintJob, which requires a GtkPrinter object, so we also use gtk_enumerate_printers() to find the selected printer. I guess gtk_enumerate_printers it's failing, that's why the error is printer not found. GtkPrintJob will probably fail too if we get the printer, though.

This is a problem for Evolution in Fedora 33.  Users are unable to print an email from within Evolution.

As a workaround, starting Evolution with:

$ WEBKIT_FORCE_SANDBOX=0 evolution

permits the behavior.

[Markus Pohle]

can confirm that this workaround works for fedora 33 users to make evolution print again

will this bug be solved in the near future?

[Luigi]

Just tested the patch and it works for me so thank-you for the patch.
Hope it is "officially" fixed in some update soon.

[Michael Gratton]

This also breaks printing to PDF from the sandbox, presumably because the destination location isn't writable.

Adding all of ~ as writable to the sandbox seems to fix it: https://gitlab.gnome.org/GNOME/geary/-/merge_requests/655 - but this (to my mind at least) makes the sandbox substantially less useful.

[Michael Catanzaro]

Yeah that effectively disables the entire sandbox. Until we manage to fix this, you should not enable the sandbox if you need printing to work.

[Michael Gratton]

(In reply to Michael Catanzaro from comment #8)
> Yeah that effectively disables the entire sandbox. Until we manage to fix
> this, you should not enable the sandbox if you need printing to work.

Well printing to PDF is an important use case (I care a lot less about printing to actual printers, tbh) so I'm going to merge that MR.

I'd be willing to consider narrowing the focus down to just say XDG_DOWNLOADS and XDG_DOCUMENTS if WebKitGTK at least produced an error signal/dialog/whatever when the operation fails, instead of doing so silently.

[Michael Catanzaro]

Just remove the code that enables the sandbox instead. That makes more sense than enabling the sandbox and allowing everything through. Also, I'll probably make it crash in the future if you try to enable access to ~, since we don't want to allow that in GTK 4, whereas you know for sure the sandbox will remain off by default for the lifetime of GTK 3 to avoid breaking existing apps. So it's better to just disable the sandbox until you're ready to try again.

[Michael Gratton]

(In reply to Michael Catanzaro from comment #10)
> Just remove the code that enables the sandbox instead.

Sure, done.

[Michael Gratton]

Is there likely to be any movement on improving completely broken printing situation in WebkitGTK under modern deployment situations?

It would be a shame to hold off the port of Geary to GTK4 because of it.

[Michael Catanzaro]

It's on my to-do list.

Michael, would love to see this fixed.  Thanks.

[Michael Catanzaro]

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

[Adam Bukolt]

The now closed https://gitlab.gnome.org/GNOME/epiphany/-/issues/1831 refers to apparently the same problem on a different flavour of Linux and and with a non-flatpak installation of Gnome Web (Epiphany). 

If it is the same issue, other applications (Epiphany, Firefox) can print both to a file and to a physical printer.

[Carlos Garcia Campos]

Let's split this, because bubblewap and flatpak require different solutions. To make it work with bubblewrap we need to move the part to handle printers to the UI process, for flatpak we need to use the portal.

[Carlos Garcia Campos]

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

[EWS]

Committed 253895@main (d5158b635f0e): <https://commits.webkit.org/253895@main>

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