202363 2019-09-30 06:59:51 -0700 [GTK] Printing not working with bubblewrap sandbox enabled 2022-08-28 23:56:38 -0700 1 1 1 Unclassified WebKit WebKitGTK Other Unspecified Unspecified RESOLVED FIXED https://bugzilla.redhat.com/show_bug.cgi?id=2004725 P2 Major --- 206533 244332 1 masterone cgarcia abukolt58 adam alex.go4more andrea.vai aperez braden bugs-noreply bugzilla bugzilla-webkit cgarcia chris dan gpoo ht990332 kip lui maierw markus.pohle matthias.andree mcatanzaro mcrha mgorse mike noein93 pgriffis robert shawn oldest_to_newest 1575251 0 masterone 2019-09-30 06:59:51 -0700 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 1575462 1 cgarcia 2019-10-01 01:14:02 -0700 Does this happen with sandboxing disabled? 1575474 2 mcatanzaro 2019-10-01 02:36:24 -0700 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. 1665305 3 cgarcia 2020-06-22 23:14:21 -0700 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. 1706841 4 dan 2020-11-12 07:07:49 -0800 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. 1709009 5 markus.pohle 2020-11-19 01:54:34 -0800 can confirm that this workaround works for fedora 33 users to make evolution print again will this bug be solved in the near future? 1714987 6 lui 2020-12-15 18:12:11 -0800 Just tested the patch and it works for me so thank-you for the patch. Hope it is "officially" fixed in some update soon. 1725082 7 mike 2021-02-03 04:34:45 -0800 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. 1725134 8 mcatanzaro 2021-02-03 07:34:03 -0800 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. 1725330 9 mike 2021-02-03 13:48:20 -0800 (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. 1725335 10 mcatanzaro 2021-02-03 14:20:00 -0800 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. 1726458 11 mike 2021-02-06 23:29:13 -0800 (In reply to Michael Catanzaro from comment #10) > Just remove the code that enables the sandbox instead. Sure, done. 1726459 12 mike 2021-02-06 23:31:43 -0800 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. 1726475 13 mcatanzaro 2021-02-07 06:36:25 -0800 It's on my to-do list. 1771008 14 shawn 2021-06-18 07:04:11 -0700 Michael, would love to see this fixed. Thanks. 1773746 15 mcatanzaro 2021-06-30 08:05:15 -0700 *** Bug 192748 has been marked as a duplicate of this bug. *** 1884032 16 abukolt58 2022-07-15 08:15:37 -0700 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. 1893679 17 cgarcia 2022-08-25 04:45:04 -0700 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. 1893682 18 cgarcia 2022-08-25 05:08:04 -0700 Pull request: https://github.com/WebKit/WebKit/pull/3651 1894412 19 ews-feeder 2022-08-28 23:56:35 -0700 Committed 253895@main (d5158b635f0e): <https://commits.webkit.org/253895@main> Reviewed commits have been landed. Closing PR #3651 and removing active labels.