Bug 202363 - [GTK] Printing not working with bubblewrap sandbox enabled
Summary: [GTK] Printing not working with bubblewrap sandbox enabled
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 206533
  Show dependency treegraph
 
Reported: 2019-09-30 06:59 PDT by Master One
Modified: 2021-03-04 00:01 PST (History)
14 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Master One 2019-09-30 06:59:51 PDT
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
Comment 1 Carlos Garcia Campos 2019-10-01 01:14:02 PDT
Does this happen with sandboxing disabled?
Comment 2 Michael Catanzaro 2019-10-01 02:36:24 PDT
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.
Comment 3 Carlos Garcia Campos 2020-06-22 23:14:21 PDT
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.
Comment 4 dan 2020-11-12 07:07:49 PST
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.
Comment 5 Markus Pohle 2020-11-19 01:54:34 PST
can confirm that this workaround works for fedora 33 users to make evolution print again

will this bug be solved in the near future?
Comment 6 Luigi 2020-12-15 18:12:11 PST
Just tested the patch and it works for me so thank-you for the patch.
Hope it is "officially" fixed in some update soon.
Comment 7 Michael Gratton 2021-02-03 04:34:45 PST
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.
Comment 8 Michael Catanzaro 2021-02-03 07:34:03 PST
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.
Comment 9 Michael Gratton 2021-02-03 13:48:20 PST
(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.
Comment 10 Michael Catanzaro 2021-02-03 14:20:00 PST
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.
Comment 11 Michael Gratton 2021-02-06 23:29:13 PST
(In reply to Michael Catanzaro from comment #10)
> Just remove the code that enables the sandbox instead.

Sure, done.
Comment 12 Michael Gratton 2021-02-06 23:31:43 PST
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.
Comment 13 Michael Catanzaro 2021-02-07 06:36:25 PST
It's on my to-do list.