Hello,

I'm aware of the recent GTK 4 hotfix for the print dialog and I'm not sure if this is related. I'm not familiar with this API or if the problem lies with WebKit, GTK, or something else, but am submitting this report to give you a lead in any case. I don't see anything obvious to suggest that CUPS is coming into play here.

When using Epiphany or the mini browser demo on unstable, merely opening the print dialog (which, I presume, probes for printers) causes a crash. Before the process terminates only the "Print to File" device is visible, but I have a couple physical printers as well as printer-driver-cups-pdf set up. I've crafted this GDB command to make the issue more obvious:
gdb --eval-command='file -readnow /usr/lib/x86_64-linux-gnu/webkitgtk-6.0/MiniBrowser' --eval-command='set args data:text/html,%3Chtml%3E%3Chead%3E%3Ctitle%3EPrint%3C%2Ftitle%3E%3Cscript%3Ewindow.onload%20%3D%20window.print%28%29%3B%3C%2Fscript%3E%3C%2Fhead%3E%3C%2Fhtml%3E%0A' --eval-command='break -force-condition ./debian/build/deb/../../../gtk/gtklistitemmanager.c:1679 if n_items'

That breakpoint refers to the file in the GTK 4 source tree where a null pointer is assigned to tile but it gets dereferenced in the loop because n_items is non-zero.
Please take a gander when you find the opportunity or let me know if help is needed reproducing the issue.

Thanks. So far I haven't been able to reproduce the issue. Does it
still happen with 2.46.3 ? (there's also 2.47.1 in experimental if you
want to give it a try)

Berto

Alberto Garcia wrote:

The issue is in GTK. I don't think this has anything to do with the CPDB/CUPS changes recently; that's just a coincidence. This issue was introduced in GTK 4.16.1 and the fix hasn't made it into a new GTK release yet, having only been made a few days ago, but perhaps the GTK maintainers can consider cherry-picking if there will be a delay.
I can confirm that merge request 7880, which fixes issue 7109 upstream, solves the issue for me and allows printing again.