Bug 212814

Summary:	[GTK] Cannot 'Export to PDF'
Product:	WebKit	Reporter:	Milan Crha <mcrha>
Component:	WebKitGTK	Assignee:	Nobody <webkit-unassigned>
Status:	REOPENED ---
Severity:	Normal	CC:	bugs-noreply, cgarcia, dev-webkit
Priority:	P2
Version:	Other
Hardware:	Unspecified
OS:	Unspecified

Description Milan Crha 2020-06-05 04:56:20 PDT

Coming from https://gitlab.gnome.org/GNOME/evolution/-/issues/974

The GTK_PRINT_OPERATION_ACTION_EXPORT action seems to be ignored by WebKitGTK (2.28.2), it always shows a print dialog, instead of exporting to the given file name. That can lead to a lot of print dialogs when dragging mouse above a Nautilus window.

It's also bad that WebKitGTK needs the main GMainContext to operate, because when it is hidden below another main context (see the upstream bug), then it just freezes the application in an indefinite wait for a request completion , which is piled in a GMainContext, which is not iterated. I do not think you can do much about this, the idea of EAsync has some caveats and this is only one of them. I only mention it here to provide a reason why the application is frozen.

Comment 1 Carlos Garcia Campos 2020-06-19 03:13:38 PDT

I'm not sure I understand. Where is WebKit expected to handle the GTK_PRINT_OPERATION_ACTION_EXPORT? We don't use gtk_print_operation_run(). webkit_print_operation_run_dialog() always shows the dialog and webkit_print_operation_print() doesn't show the dialog.

Comment 2 Milan Crha 2020-06-22 02:46:13 PDT

Oh, I see, that's some misunderstanding on the Evolution side. After looking around the code with the pointers you gave me I see the action is not even used, which is a shame. I'm sorry for a false bug report.

Comment 3 Milan Crha 2020-11-05 10:28:00 PST

I'm reopening this. I tried to use webkit_print_operation_print(), but it fails with "Printer not found". Remember, I only want to Export to PDF file, not to print anything on a real printer hardware.

I chose "Print to File" printer (I found that name in the WebKit tests). That failed due to sandbox (bug #202363), thus I worked around it by using WEBKIT_FORCE_SANDBOX=0. When I run the application in other than English-like locale the printer cannot be found again (because it's not named "Print to File" in that locale). I'm pretty sure your internal tests will also fail when you run them in other than the English-like locale.

That being said, is there a way to just pass a file name to the WebKit and it'll populate the file content with the PDF data? The gtk+ itself uses GTK_PRINT_OPERATION_ACTION_EXPORT and uses the file name set by the gtk_print_operation_set_export_filename(). It does not need any printer set, it's just for the "Export to PDF" action.

Comment 4 dev-webkit 2024-07-17 03:07:48 PDT

WebKitGtk is used as a webview for Tauri, a light application framework, an alternative to electron. Currently it is missing a print API but this bug is going to prevent it from having a complete print API with PDF generation.

See: https://github.com/tauri-apps/tauri/issues/4917#issuecomment-2232928109

Comment 5 dev-webkit 2024-07-23 14:38:54 PDT

It seems printing to file is already implemented, it's just a matter of providing an API for it.

In WebKitPrintOperation.cpp there is the function findFilePrinter that selects the proper printer for file printing and the function webkitPrintOperationSendPagesToPrintPortal that uses it to create a printed file.