Bug 202363 - [GTK] Printing not working with bubblewrap sandbox enabled
Summary: [GTK] Printing not working with bubblewrap sandbox enabled
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Major
Assignee: Carlos Garcia Campos
URL:
Keywords:
Depends on:
Blocks: Bubblewrap 244332
  Show dependency treegraph
 
Reported: 2019-09-30 06:59 PDT by Master One
Modified: 2022-08-28 23:56 PDT (History)
27 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.
Comment 14 shawn 2021-06-18 07:04:11 PDT
Michael, would love to see this fixed.  Thanks.
Comment 15 Michael Catanzaro 2021-06-30 08:05:15 PDT
*** Bug 192748 has been marked as a duplicate of this bug. ***
Comment 16 Adam Bukolt 2022-07-15 08:15:37 PDT
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.
Comment 17 Carlos Garcia Campos 2022-08-25 04:45:04 PDT
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.
Comment 18 Carlos Garcia Campos 2022-08-25 05:08:04 PDT
Pull request: https://github.com/WebKit/WebKit/pull/3651
Comment 19 EWS 2022-08-28 23:56:35 PDT
Committed 253895@main (d5158b635f0e): <https://commits.webkit.org/253895@main>

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