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
Does this happen with sandboxing disabled?
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.
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.
can confirm that this workaround works for fedora 33 users to make evolution print again will this bug be solved in the near future?
Just tested the patch and it works for me so thank-you for the patch. Hope it is "officially" fixed in some update soon.
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.
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.
(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.
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.
(In reply to Michael Catanzaro from comment #10) > Just remove the code that enables the sandbox instead. Sure, done.
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.
It's on my to-do list.
Michael, would love to see this fixed. Thanks.
*** Bug 192748 has been marked as a duplicate of this bug. ***
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.
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.
Pull request: https://github.com/WebKit/WebKit/pull/3651
Committed 253895@main (d5158b635f0e): <https://commits.webkit.org/253895@main> Reviewed commits have been landed. Closing PR #3651 and removing active labels.