gtk issueshttps://gitlab.gnome.org/GNOME/gtk/-/issues2024-03-13T16:06:25Zhttps://gitlab.gnome.org/GNOME/gtk/-/issues/6265New Security Issue2024-03-13T16:06:25ZGitLab Support BotNew Security IssueOriginal reporter: [Daniel Holbert](mailto:dholbert@mozilla.com)
Area: Platform component (libraries, tools)
## Message
I work at Mozilla on Firefox's printing components, and we ran across a security-sensitive crash (a use-after-free...Original reporter: [Daniel Holbert](mailto:dholbert@mozilla.com)
Area: Platform component (libraries, tools)
## Message
I work at Mozilla on Firefox's printing components, and we ran across a security-sensitive crash (a use-after-free) in Firefox, which turns out to be a bug in libgtk3, which is reproducible in Firefox as well as with a minimal c++ testcase.
It manifests as a crash in the function `gtk_printer_get_name`, when running a program that calls "gtk_enumerate_printers" on systems that use a remote CUPS server. More details below.
This crash is actually already filed as https://gitlab.gnome.org/GNOME/gtk/-/issues/4672 , but when my colleague Emilio filed that issue, we weren't aware that it was a use-after-free. (Our crash reports were mistakenly reporting the access address as being a nullptr dereference, when in fact they were using a freed pointer.) It's of course your call whether it's better to morph that issue into a private bug, vs. track this in a new report, vs. something else.
We've found that an effective workaround in Firefox is to simply let gtk_enumerate_printers complete a full enumeration -- the crash only happens when the enumeration callback function returns true and stops the enumeration partway through. We're shipping that workaround (https://hg.mozilla.org/mozilla-central/rev/833e0bfa6d81 ) to mitigate the crash in Firefox, but I wanted to also report the bug upstream to you.
Here's a rough overview of what goes wrong, when the crash happens (based on my debugging/analysis when diagnosing this in Firefox):
* The client program calls `gtk_enumerate_printers`, passing in an enumeration callback function.
* `gtk_enumerate_printers` calls `list_printers_init`, which [sets up a callback-handler for the named signal `"printer-added"`](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/gtk/print/gtkprinter.c#L1275-L1277), wiring that signal up to call [`list_added_cb()`](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/gtk/print/gtkprinter.c#L1189), which (when called) will call the client program's enumeration callback function.
* Later on, we find ourselves in [`cups_request_printer_list_cb()`](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/modules/printbackends/gtkprintbackendcups.c#L3643) to handle a response from the cups server with printer info.
* In that `cups_request_printer_list_cb` function, we [set up a local linked-list of printers, `removed_printer_checklist`](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/modules/printbackends/gtkprintbackendcups.c#L3684) that we're comparing against and modifying as-we-go for some reason. This is the list that's going to get us into trouble!!
* The main loop of `cups_request_printer_list_cb` [iterates over the CUPS response data](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/modules/printbackends/gtkprintbackendcups.c#L3686-L3688), [generating GtkPrinter instances](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/modules/printbackends/gtkprintbackendcups.c#L3763-L3764) as it goes.
* AND, during that loop: each time it creates a new `GtkPrinter`, it [sends the `"printer-added"` signal](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/modules/printbackends/gtkprintbackendcups.c#L3801), which synchronously invokes the `list_added_cb` callback that I discussed at the start here.
* `list_added_cb` calls the client program's own custom enumeration-callback-function. If that function returns true to stop the enumeration, then **a bunch of data gets deleted (which is a problem since that data is still referenced in removed_printer_checklist)**!! Specifically, that deletion happens as follows: `list_added_cb` [calls `stop_enumeration`](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/gtk/print/gtkprinter.c#L1195), which [calls `list_done_cb`](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/gtk/print/gtkprinter.c#L1169), which calls [`list_printers_remove_backend`](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/gtk/print/gtkprinter.c#L1242) which [destroys the print backend and frees the printer list](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/gtk/print/gtkprinter.c#L1222-L1227).
* Then we unwind back up to the `cups_request_printer_list_cb` loop (where we dispatched the "printer-added" signal from), and we keep looping over the cups response data; and when we get to the part where we try to [search in our `removed_printer_checklist`](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/modules/printbackends/gtkprintbackendcups.c#L3753-L3756) linked-list of `GtkPrinter*` pointers, we find that the `GtkPrinter*` pointers in our linked list are all pointing to garbage data, and we potentially **crash with a use-after-free** when getting their name in `gtk_printer_get_name`. Or, if we're lucky, we notice that the freed object's data doesn't look right for a `GtkPrinter`, and we [bail out from gtk_printer_get_name via the `g_return_if_fail(GTK_IS_PRINTER(...))` early-return](https://github.com/GNOME/gtk/blob/0b0a5a52af59b50a83f9cf4594d9beb606af36c6/gtk/print/gtkprinter.c#L451-L455).
* (That `g_return_if_fail` statement can be seen-to-be-failing via the environmental variable `G_DEBUG=fatal-criticals`, so that this manifests as a crash even if we're lucky enough (as we usually are) for the deleted object to be detected as garbage by that check.)
I've got a sample minimal C++ program that triggers the bug, which I'm happy to provide the source for, though it appears this form doesn't let me include attachments. Please let me know how best to submit that; maybe as an attachment on the bug that results from this submission?
Thanks!
~Daniel Holbert2024-03-13https://gitlab.gnome.org/GNOME/gtk/-/issues/6126windows: Support GtkPrintDialog2023-09-28T10:39:41ZMatthias Clasenwindows: Support GtkPrintDialogIt would be good to have an implementation of GtkPrintDialog that uses the native Windows print api.
I tried to write one using GtkPrintOperation, but that did not work out, since it does not have
a 'print this file' api.It would be good to have an implementation of GtkPrintDialog that uses the native Windows print api.
I tried to write one using GtkPrintOperation, but that did not work out, since it does not have
a 'print this file' api.https://gitlab.gnome.org/GNOME/gtk/-/issues/6124Printing goes to the wrong destination2023-09-28T11:49:56ZMatthias ClasenPrinting goes to the wrong destinationI am observing this with the loupe-45 rpm in F39:
- open the print dialog
- select 'print to file'
- choose a filename
- click print
- the loupe print options dialog comes up, saying 'Print to File' in the subtitle
- click print
- the p...I am observing this with the loupe-45 rpm in F39:
- open the print dialog
- select 'print to file'
- choose a filename
- click print
- the loupe print options dialog comes up, saying 'Print to File' in the subtitle
- click print
- the printjob gets sent to my actual printerhttps://gitlab.gnome.org/GNOME/gtk/-/issues/6123Empty tabs on print dialog when no printer is selected2023-09-28T15:17:29ZMichael CatanzaroEmpty tabs on print dialog when no printer is selectedUsing today's GTK git main, I've opened Loupe's print dialog and then clicked on the Image Quality tab without first selecting a printer. It looks empty and broken:
![Screenshot_from_2023-09-26_19-29-12](/uploads/b108deaa23f2dd37481d2ad...Using today's GTK git main, I've opened Loupe's print dialog and then clicked on the Image Quality tab without first selecting a printer. It looks empty and broken:
![Screenshot_from_2023-09-26_19-29-12](/uploads/b108deaa23f2dd37481d2ade04bf8521/Screenshot_from_2023-09-26_19-29-12.png)
Same problem occurs for the Color, Finishing, and Advanced tabs. Probably all these tabs should be insensitive until a printer has been selected.https://gitlab.gnome.org/GNOME/gtk/-/issues/5987Glossy paper not showing up in printing dialog for hp photosmart 55102023-09-17T14:19:49ZJulian SikorskiGlossy paper not showing up in printing dialog for hp photosmart 5510I originally reported this to CUPS but was told this is likely an external issue:
https://github.com/OpenPrinting/cups/issues/766
Summing up, glossy paper is not showing up for selection in the print dialog even though it is supported by...I originally reported this to CUPS but was told this is likely an external issue:
https://github.com/OpenPrinting/cups/issues/766
Summing up, glossy paper is not showing up for selection in the print dialog even though it is supported by the driver.
## Steps to reproduce
1. Install a hp 5510 series printer using hpcups driver from hplip-3.23.5
2. Open a photo in eog
3. Pick print
4. Go to page setup
5. Open paper type dropdown
## Current behavior
Only Transparency film and Normal paper are shown.
## Expected outcome
Glossy paper is shown as well.
## Version information
- gtk3-3.24.38-1.fc38.x86_64 and gtk4-4.10.4-1.fc38.x86_64
- Fedora 38uilt GTK yourself, the list of options used to configure the build
## Additional information
If system dialog is invoked from firefox, glossy paper is being shown, but it shows conflicts even for settings not conflicting according to the PPD file:
![Bildschirmfoto_vom_2023-07-27_09-36-09](/uploads/8af04ae9c1eb8092e7370b44e21fce28/Bildschirmfoto_vom_2023-07-27_09-36-09.png)
![Bildschirmfoto_vom_2023-07-27_09-36-19](/uploads/92dc2af6ccbd5a6d5be230dfc50b247a/Bildschirmfoto_vom_2023-07-27_09-36-19.png)
```
*UIConstraints: *MediaType Plain *OutputMode Photo
*UIConstraints: *OutputMode Photo *MediaType Plain
*UIConstraints: *MediaType Glossy *OutputMode FastDraft
*UIConstraints: *OutputMode FastDraft *MediaType Glossy
*UIConstraints: *MediaType TransparencyFilm *OutputMode FastDraft
*UIConstraints: *OutputMode FastDraft *MediaType TransparencyFilm
*UIConstraints: *MediaType TransparencyFilm *OutputMode Best
*UIConstraints: *OutputMode Best *MediaType TransparencyFilm
*UIConstraints: *MediaType TransparencyFilm *OutputMode Photo
*UIConstraints: *OutputMode Photo *MediaType TransparencyFilm
*UIConstraints: *PageSize A5 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize A5
*UIConstraints: *PageSize JB5 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize JB5
*UIConstraints: *PageSize Executive *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize Executive
*UIConstraints: *PageSize A4 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize A4
*UIConstraints: *PageSize Letter *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize Letter
*UIConstraints: *PageSize Legal *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize Legal
*UIConstraints: *PageSize A6 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize A6
*UIConstraints: *PageSize Card3x5 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize Card3x5
*UIConstraints: *PageSize Card4x6 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize Card4x6
*UIConstraints: *PageSize Card5x8 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize Card5x8
*UIConstraints: *PageSize EnvChou4 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize EnvChou4
*UIConstraints: *PageSize EnvA2 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize EnvA2
*UIConstraints: *PageSize EnvC6 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize EnvC6
*UIConstraints: *PageSize EnvChou3 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize EnvChou3
*UIConstraints: *PageSize EnvMonarch *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize EnvMonarch
*UIConstraints: *PageSize Env10 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize Env10
*UIConstraints: *PageSize EnvDL *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize EnvDL
*UIConstraints: *PageSize EnvC5 *MediaType Glossy
*UIConstraints: *MediaType Glossy *PageSize EnvC5
```https://gitlab.gnome.org/GNOME/gtk/-/issues/5841User-specified print settings in GTK applications are silently overriden by s...2023-06-23T09:22:09ZSym SilUser-specified print settings in GTK applications are silently overriden by system printer defaults and/or just have no effectI originally posted this issue to the GNOME Settings forum, but I think it may be more appropriate here or perhaps needs attention in both places.
Here is the original post: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2...I originally posted this issue to the GNOME Settings forum, but I think it may be more appropriate here or perhaps needs attention in both places.
Here is the original post: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2463
I re-opened this issue because the workaround I outlined is not really a proper solution. The issue begs for a definitive solution that would presumably involve identifying the root cause and devising a remedy by GTK+ developers/maintainers, CUPS developers/maintainers, and/or others.
When searching for a solution earlier, I came across a handful of forum posts, scattered over a span of several years, that seemed to describe the same problem, but there was never a solution provided.
Even in our single organization's use-case, the workaround proposed would require a significant amount of manual intervention on many different workstations, each of which uses a range of different printers, depending on location.
Identifying and remedying the root problem seems like it should be a priority, given the problematic nature of this issue related to basic printing and the persistence of this sort of problem over many years, as evidenced by unanswered forum posts and appeals for help by different community members over the past several years.https://gitlab.gnome.org/GNOME/gtk/-/issues/5816Move printing to a separate library2023-09-29T11:31:13ZMatthias ClasenMove printing to a separate libraryThe printing parts of gtk are fairly standalone.
We really don't want to carry this api surface forward if we can help it.
- Moving printing to a separate library and maybe even a separate project would be a logical step
- Move print d...The printing parts of gtk are fairly standalone.
We really don't want to carry this api surface forward if we can help it.
- Moving printing to a separate library and maybe even a separate project would be a logical step
- Move print dialogs to that dialog as well, or move it directly to the portal backends
- We may still want to keep a simplified print api in gtk, like the one sketched out here: https://gitlab.gnome.org/GNOME/gtk/-/issues/5562https://gitlab.gnome.org/GNOME/gtk/-/issues/5727printing: Allow to change the "Print" label on button2023-05-11T14:59:19ZSophie Heroldprinting: Allow to change the "Print" label on buttonTL;DR: I want something like `PrintOperation.set_accept_label()` to change the label of the "Print" button.
This also needs a new option key in the print portal.
## Reason
As discussed in the chat a while ago, I need a way to set up t...TL;DR: I want something like `PrintOperation.set_accept_label()` to change the label of the "Print" button.
This also needs a new option key in the print portal.
## Reason
As discussed in the chat a while ago, I need a way to set up the image on the page for printing. EOG and Photos used the "custom tab" feature for that. My solution that also works with Flatpaks is the following:
1. Normal print dialog to select the printer and all the settings
2. After pressing the "Print" button, show a custom dialog (early test below) to do the layout things
3. After pressing "Print" here, start the printing
Of course, in this case, the suggested action button in the print dialog should not be called "Print," but something custom.
![image](/uploads/201c59b74596f523668e06a86b6df1d3/image.png)
## Custom Tabs
![image](/uploads/300b486c9b4f4803f1c3cf4a7341a1da/image.png)
![image](/uploads/ca9d8d5653a722e2a9fe12444f903178/image.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/5726printing: ACTION_PRINT and ACTION_PRINT_DIALOG are handled identically2023-08-21T18:43:57ZSophie Heroldprinting: ACTION_PRINT and ACTION_PRINT_DIALOG are handled identically`GTK_PRINT_OPERATION_ACTION_PRINT` should not open the print dialog but it does when using the portal.
The reason is that `gtk_print_operation_portal_run_dialog` does not abide by the `show_dialog` flag. Instead of using the `Print` fun...`GTK_PRINT_OPERATION_ACTION_PRINT` should not open the print dialog but it does when using the portal.
The reason is that `gtk_print_operation_portal_run_dialog` does not abide by the `show_dialog` flag. Instead of using the `Print` function from the portal if `show_dialog=false`, it always uses `PreparePrint`.https://gitlab.gnome.org/GNOME/gtk/-/issues/5719printing: Support other resolutions than 72 DPI2023-04-08T22:45:20ZSophie Heroldprinting: Support other resolutions than 72 DPIAs I understand it, 72 DPI is currently hardcoded for printing via Cairo. I wonder if I'm overlooking something or if there is a different option.
Otherwise, it would be nice if it was possible to get a GtkPrintContext with either custo...As I understand it, 72 DPI is currently hardcoded for printing via Cairo. I wonder if I'm overlooking something or if there is a different option.
Otherwise, it would be nice if it was possible to get a GtkPrintContext with either custom values or maybe just the minimum of x/y resolution in the GtkPrintSettings.
- https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkprintoperation-portal.c#L324
- https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gtk/gtkprintoperation-unix.c#L583https://gitlab.gnome.org/GNOME/gtk/-/issues/5589cpdb backend doesn't compile2023-02-14T23:48:45ZJeremy Bichacpdb backend doesn't compile- GTK 4.9.4
- cpdb-libs 1.2.0
- Debian Unstable
I set `-Dprint-cpdb=enabled` and gtk fails to build:
```
Run-time dependency cpdb-frontend found: NO (tried pkgconfig)
../../../modules/printbackends/meson.build:13:0: ERROR: Dependency ...- GTK 4.9.4
- cpdb-libs 1.2.0
- Debian Unstable
I set `-Dprint-cpdb=enabled` and gtk fails to build:
```
Run-time dependency cpdb-frontend found: NO (tried pkgconfig)
../../../modules/printbackends/meson.build:13:0: ERROR: Dependency "cpdb-frontend" not found, tried pkgconfig
```
On my system, the pkgconf file provided by `libcpdb-libs-frontend-dev` is `cpdb-libs-frontend.pc` so I changed my copy of modules/printbackends/meson.build to use that name on its dependency line instead (drop the `.pc` suffix).
And then I get:
```
../../../modules/printbackends/gtkprintbackendcpdb.c:22:10: fatal error: cpdb/frontend.h: No such file or directory
22 | #include <cpdb/frontend.h>
| ^~~~~~~~~~~~~~~~~
compilation terminated.
```
cpdb-libs provides `cpdb-libs-frontend.h` so I changed the include lines in my copy of both gtkprintercpdb.h and gtkprintbackendcpdb.c
Then I got a lot of errors and warnings and the build failed.
```
In file included from ../../../modules/printbackends/gtkprintercpdb.c:19:
../../../modules/printbackends/gtkprintercpdb.h:34:3: error: unknown type name ‘cpdb_printer_obj_t’
34 | cpdb_printer_obj_t *printer_obj;
| ^~~~~~~~~~~~~~~~~~
../../../modules/printbackends/gtkprintercpdb.h:39:1: error: unknown type name ‘cpdb_printer_obj_t’
```
cc/ @tinytrebuchet @till.kamppeterhttps://gitlab.gnome.org/GNOME/gtk/-/issues/5562Simplified print api2023-11-22T19:04:21ZMatthias ClasenSimplified print apiHere is a suggestion for a new high-level print api that is modeled
after the print portal and focuses on the 'print an existing pdf'
case. We intentionally consider the 'generate pdf' task out of scope here.
```
/**
* gtk_print_dialog...Here is a suggestion for a new high-level print api that is modeled
after the print portal and focuses on the 'print an existing pdf'
case. We intentionally consider the 'generate pdf' task out of scope here.
```
/**
* gtk_print_dialog_prepare_print:
* @self: a `GtkPrintDialog`
* @parent: (nullable): the parent `GtkWindow`
* @initial_settings: (nullable): the initial print settings
* @default_page_setup: (nullable): the default page setup
* @cancelable: (nullable): a `GCancellable` to cancell the operation
* @callback: (sope async): a callback to clal when the operation is complete
* @user_data: (closure callback): data to pass to @callback
*
* Presents a print dialog to the user to configure
* print settings and page setup.
*
* The @callback will be called when the dialog is dismissed.
* t should call [method@Gtk.PrintDialog.prepare_print_finish]
* to obtain the results.
*/
void
gtk_print_dialog_prepare_print (GtkPrintDialog *self,
GtkWindow *parent,
GtkPrintSettings *initial_settings,
GtkPageSetup *default_page_setup,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
/**
* gtk_print_dialog_prepare_finish:
* @self: a `GtkPrintDialog`
* @result: a `GAsyncResult`
* @settings: (out): return location for the print settings
* @page_setup: (out): return location for the page setup
* @error: return location for a [enum@Gtk.DialogError] error
*
* Finishes the [method@Gtk.PrintDialog.prepare_print] call and
* returns the results.
*
* Returns: a token that can be passed to [method@Gtk.PrintDialog.print]
* to bypass the print dialog, or 0 in case @error is set
*/
unsigned int
gtk_print_dialog_prepare_print_finish (GtkPrintDialog *self,
GAsyncResult *result,
GtkPrintSettings **settings,
GtkPageSetup **page_setup,
GError **error)
/**
* gtk_print_dialog_print:
* @self: a `GtkPrintDialog`
* @parent: (nullable): the parent `GtkWindow`
* @token: token received from [method@Gtk.PrintDialog.prepare_print], or 0
* @content: a `GInputStream` to read the content from
* @cancellable: (nullable): a `GCancellable` to cancel the operation
* @callback: (sope async): a callback to clal when the operation is complete
* @user_data: (closure callback): data to pass to @callback
*
* Asks to print formatted content, typically formatted as pdf.
*
* The file is passed in the form of an input stream.
*
* If @token is a valid token that was obtained via [method@Gtk.PrintDialog.prepare_print],
* then the printing will use the settings (including the which printer
* to use) from the call that the token refers to. If the token is 0,
* then a print dialog will be presented to the user.
*/
void
gtk_print_dialog_print (GtkPrintDialog *self,
GtkWindow *parent,
unsigned int token,
GInputStream *content,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data)
/**
* gtk_print_dialog_print_finish:
* @self: a `GtkPrintDialog`
* @result: a `GAsyncResult`
* @error: return location for a [enum@Gtk.DialogError] error
*
* Finishes the [method@Gtk.PrintDialog.print] call and
* returns the results.
*
* Returns: True if the printing was successful, false if
* @error is set
*/
gboolean
gtk_print_dialog_print_finish (GtkPrintDialog *self,
GAsyncResult *result,
GError **error)
```https://gitlab.gnome.org/GNOME/gtk/-/issues/5019GtkPrintBackend not being finalized/disposed when running the "Printing" dial...2022-07-13T14:03:26ZTinyTrebuchetGtkPrintBackend not being finalized/disposed when running the "Printing" dialog from Gtk Demo binary after compiling GTK## Steps to reproduce
1. Compile gtk (`meson setup --prefix /opt/gtk _builddir && cd _builddir && ninja && ninja install`)
2. Export new library path: `export LD_LIBRARY_PATH="/opt/gtk/lib/x86_64-linux-gnu/"`
3. Run Gtk Demo binary: ...## Steps to reproduce
1. Compile gtk (`meson setup --prefix /opt/gtk _builddir && cd _builddir && ninja && ninja install`)
2. Export new library path: `export LD_LIBRARY_PATH="/opt/gtk/lib/x86_64-linux-gnu/"`
3. Run Gtk Demo binary: `/opt/gtk/bin/gtk4-demo`
4. Run and close the "Printing" dialog
## Current behavior
When opening the "Printing" dialog from Gtk4 Demo binary, I get `CUPS Backend: Initializing CUPS backend module` on the terminal.
But after closing the "Printing" dialog, GtkPrintBackend doesn't seem to get finalized, and nothing is logged on the terminal.
I am designing my own GtkPrintBackend, and mine doesn't get finalized either.
Also, the memory increases roughly by 10MB every 3-4 times I open and close the Print Dialog (if I am not mistaken). The memory is freed only when I close the entire Gtk4 Demo binary.
However, the "Page Setup" dialog, everything seems to be working fine.
When opening the "Page Setup" dialog, I get `CUPS Backend: Initializing CUPS backend module`
and when closing it, I get
```
CUPS Backend: gtk_print_backend_cups_dispose
CUPS Backend: gtk_print_backend_cups_dispose
CUPS Backend: finalizing CUPS backend module
```
as expected.
## Expected outcome
GtkPrintDialog gets finalized every time I close the "Printing" Dialog.
## Version information
Compiling latest version of GTK cloned from github.Marek KašíkMarek Kašíkhttps://gitlab.gnome.org/GNOME/gtk/-/issues/4672Crash when enumerating printers with remote CUPS server.2023-12-21T02:06:33ZEmilio Cobos ÁlvarezCrash when enumerating printers with remote CUPS server.We got a report of Firefox crashing when trying to print with a remote CUPS server.
The first print job seems to work fine, the second one crashes when enumerating printers deep in GTK internals, see stack here:
https://crash-stats.moz...We got a report of Firefox crashing when trying to print with a remote CUPS server.
The first print job seems to work fine, the second one crashes when enumerating printers deep in GTK internals, see stack here:
https://crash-stats.mozilla.org/report/index/782429e7-d7d4-43d7-91d7-65a520220118
Seems like a null deref / passing a null name to `gtk_printer_get_name` from `find_printer`.https://gitlab.gnome.org/GNOME/gtk/-/issues/4628GtkPrintJob API wart2022-01-25T11:15:19ZChristian PerschGtkPrintJob API wart`gtk_print_job_set_source_fd` doesn't take ownership of the passed file descriptor, so one has to manually track the ownership from outside. Every other way that `priv->spool_io` is being set creates it with the `close_on_unref` flag set...`gtk_print_job_set_source_fd` doesn't take ownership of the passed file descriptor, so one has to manually track the ownership from outside. Every other way that `priv->spool_io` is being set creates it with the `close_on_unref` flag set.
Since fixing that would be an API break, I guess this can't be fixed before gtk5.
gtk-3-24 (also present on master).https://gitlab.gnome.org/GNOME/gtk/-/issues/4627GtkPrintJob set_source_fd/file leaks existing IO channel2022-01-12T19:37:19ZChristian PerschGtkPrintJob set_source_fd/file leaks existing IO channelWhen using both `gtk_print_job_set_source_fd()` *and* `gtk_print_job_set_source_file()` on the same `GtkPrintJob` (as `xdg-desktop-portal-gnome` does at [here](https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src/print...When using both `gtk_print_job_set_source_fd()` *and* `gtk_print_job_set_source_file()` on the same `GtkPrintJob` (as `xdg-desktop-portal-gnome` does at [here](https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src/print.c#L288) and [here](https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/blob/main/src/print.c#L307)), the existing `priv->spool_io` channel is leaked since neither function clears it before assigning a new object.
gtk-3-24 (also present on master)https://gitlab.gnome.org/GNOME/gtk/-/issues/4439print without dialog2022-02-05T22:56:00ZRogerio Scholz Machadoprint without dialogprint with the option GTK_PRINT_OPERATION_ACTION_PRINT don't work the events 'begin-print' or 'draw-page' is never calledprint with the option GTK_PRINT_OPERATION_ACTION_PRINT don't work the events 'begin-print' or 'draw-page' is never calledhttps://gitlab.gnome.org/GNOME/gtk/-/issues/4267Print dialog accepts Chinese wide digits, prints wrong page2021-09-20T02:37:25ZAdam BrandizziPrint dialog accepts Chinese wide digits, prints wrong page<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce...<!--
Please, read the CONTRIBUTING.md guide on how to file a new issue.
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/CONTRIBUTING.md
-->
## Steps to reproduce
<!--
Please, explain the sequence of actions necessary to reproduce the
bug
-->
1. Open a PDF file with Evince with more than one page. ([The attached file](/uploads/b4313f119bae44882e98781035b5a478/Exercicios_Extras_-_Modulo_10_.pdf) is the one which the issue first was reproduced.)
2. Open the Print dialog (either through the menu, or pressing <kbd>Ctrl</kbd>+<kbd>P</kbd>).
3. Choose to print to a file, choose the name of the file.
4. Select the "Pages" option, copy and paste the character <kbd>2</kbd> in the input.
5. Click in the "Print" button.
6. Open the output file.
<!--
You should try and reproduce with the demos applications available
under the `demos` directory, or the test programs in the `tests` directory.
Alternatively, please attach a *small and self-contained* example
*written in C* that exhibits the issue.
-->
## Current behavior
<!--
Please describe the current behaviour
-->
The first page of the document is printed.
## Expected outcome
<!--
Please describe the expected outcome
-->
Either the dialog box would reject the character (since it is not the "real" <kbd>2</kbd> digit) or would print the second page.
## Version information
<!--
- Which version of GTK you are using
- What operating system and version
- For Linux, which distribution
- If you built GTK yourself, the list of options used to configure the build
-->
## Additional information
<!--
- Screenshots or screen recordings are useful for visual errors
- Attaching a screenshot or a video without explaining the current
behavior and the actions necessary to reproduce the bug will lead
to the bug being closed
- Please report any warning or message printed on the terminal
-->
You can reproduce that by installing e.g. ibus-libpinyin and typing <kbd>2</kbd> as well, although it may be a bit more complicated.https://gitlab.gnome.org/GNOME/gtk/-/issues/4025Print dialog box shows same printer twice (due to DNS-SD?)2021-06-14T15:03:35ZTimur TabiPrint dialog box shows same printer twice (due to DNS-SD?)I originally filed this bug against Ubuntu, but it appears to be a GTK bug. Please see https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1931612
I'm using Kubuntu 20.04.2 LTS, which has libgtk-3-0:amd64 installed.
I have set up a si...I originally filed this bug against Ubuntu, but it appears to be a GTK bug. Please see https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1931612
I'm using Kubuntu 20.04.2 LTS, which has libgtk-3-0:amd64 installed.
I have set up a single HP printer which is attached to my network. The setup process went smoothly, and when I open the Printers system setup panel, I see only my printer there.
However, when I print from an application, and that application uses the system print dialog box, my printer appears twice. One entry, matching the name correctly, works fine. The other, which a slightly changed name, does not work at all. See attached screenshot.
Applications that have their own print dialog box do not have this problem. For example, Firefox shows only my printer once. Same thing with Libre Office.
I've attached two screenshots.
![Screenshot_20210611_102044](/uploads/c08723f12cd547e230ee2fd0575ff9ee/Screenshot_20210611_102044.png)
![Screenshot_20210609_104933](/uploads/0b78ca6df0e66b670af82525d6b4f451/Screenshot_20210609_104933.png)https://gitlab.gnome.org/GNOME/gtk/-/issues/3836On windows `GtkPrintSettings` can be corrupted - no print dialog is shown2021-11-02T15:47:51ZFabian KeßlerOn windows `GtkPrintSettings` can be corrupted - no print dialog is shownOn Windows, a driver/windows or GTK update can result in a corrupted `GtkPrintSettings`, which prevents Software utilizing it from opening the print dialog.
## Steps to reproduce
1. Use a software which utilizes `GtkPrintSettings`
1...On Windows, a driver/windows or GTK update can result in a corrupted `GtkPrintSettings`, which prevents Software utilizing it from opening the print dialog.
## Steps to reproduce
1. Use a software which utilizes `GtkPrintSettings`
1. Print
1. Update Windows / gtk
1. Use the same software and try to print again
1. Sometimes no Print Dialog will occur
Alternative:
1. Download corrupted ini file
2. Use it as input for `GtkPrintSettings`
1. Use the same software and try to print again
1. No Print Dialog will occur
## Current behavior
Print Dialog is not shown with corrupted `GtkPrintSettings`
## Expected outcome
Print Dialog is shown, but `GtkPrintSettings` are reset.
## Version information
libgtk-version: 3.24.23
OS: Windows
## Additional information
Corrupted File:
[print-config.ini](/uploads/7141b1a1063c2031f60c3b82d18d8910/print-config.ini)
Code:
```cpp
void PrintHandler::print(Document* doc, int currentPage) {
auto filepath = Util::getConfigFile(PRINT_CONFIG_FILE);
GtkPrintSettings* settings = gtk_print_settings_new_from_file(filepath.u8string().c_str(), nullptr);
if (settings == nullptr) {
settings = gtk_print_settings_new();
}
this->doc = doc;
GtkPrintOperation* op = gtk_print_operation_new();
gtk_print_operation_set_print_settings(op, settings);
gtk_print_operation_set_n_pages(op, doc->getPageCount());
gtk_print_operation_set_current_page(op, currentPage);
gtk_print_operation_set_job_name(op, "Xournal++");
gtk_print_operation_set_unit(op, GTK_UNIT_POINTS);
gtk_print_operation_set_use_full_page(op, true);
g_signal_connect(op, "draw_page", G_CALLBACK(drawPage), this);
g_signal_connect(op, "request-page-setup", G_CALLBACK(requestPageSetup), this);
GtkPrintOperationResult res =
gtk_print_operation_run(op, GTK_PRINT_OPERATION_ACTION_PRINT_DIALOG, nullptr, nullptr);
if (res == GTK_PRINT_OPERATION_RESULT_APPLY) {
g_object_unref(settings);
settings = gtk_print_operation_get_print_settings(op);
gtk_print_settings_to_file(settings, filepath.u8string().c_str(), nullptr);
settings = nullptr;
}
g_object_unref(op);
this->doc = nullptr;
}
```
Linked Issue: https://github.com/xournalpp/xournalpp/issues/2974