Fix astroid webextension process crashing in thread view

[ibuclaw]

Not sure what caused this to occur, looking at local system upgrade history, webkit2gtk recently got updated from 2.50.4 to 2.52.3.

To reproduce, open any email in a new thread view, and the new tab is just a blank white page that doesn't respond to any keybindings. Closing astroid then results in a segfault inside the dtor for PageClient.

First sign that something is going wrong was this error in the console.

(process:170163): Gtk-CRITICAL **: 18:16:38.827: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed

Which occurs inside the call to Gtk::IconTheme::get_default();
https://github.com/astroidmail/astroid/blob/master/src/modes/thread_view/webextension/tvextension.cc#L133

Subsequently, the return value assigned to theme is NULL. Which then results in the web extension thread dying due to the null dereference on the next line of code.

As far as I can tell, this static method expects the default screen to have already been opened, and adding an assert confirmed that no display is open inside the web extension thread.

g_assert (Gdk::Display::get_default ());

$ ./build/astroid
...
ERROR:astroid/src/modes/thread_view/webextension/tvextension.cc:132:AstroidExtension::AstroidExtension(WebKitWebExtension*, gpointer): assertion failed: (Gdk::Display::get_default ())
Bail out! ERROR:astroid/src/modes/thread_view/webextension/tvextension.cc:132:AstroidExtension::AstroidExtension(WebKitWebExtension*, gpointer): assertion failed: (Gdk::Display::get_default ())

This change reflects some observations from looking within gtk and gdk itself.

https://github.com/GNOME/gtkmm/blob/2160941ea7e63daa74782e53c7089659b5628293/gtk/gtkmm/init.cc#L28

https://github.com/GNOME/gtk/blob/0e4930b10bdee987d1e79cdc11494c953f621433/gdk/gdk.c#L371

[ibuclaw]

Keeping this here, as race condition is still possible, even though you'd have to close astroid within milliseconds of opening a new thread view.

[gauteh]

Looks good. Is it ready to merge? The debian CI may be old, and ready for disabling?

[ibuclaw]

Looks good. Is it ready to merge? The debian CI may be old, and ready for disabling?

CI does need updating indeed. I wonder if the tests might trip the issue I'm seeing if tried on a newer distro version.

[ibuclaw]

Managed to synthesise the failure in CI

https://github.com/astroidmail/astroid/actions/runs/26133623364/job/76863863768?pr=772#step:7:174

https://github.com/astroidmail/astroid/actions/runs/26133623364/job/76863863755?pr=772#step:7:177

@gauteh I guess it's ready if all's now green.

[ibuclaw]

Still failures on ubuntu noble, but curiously not on ubuntu resolute.

https://github.com/astroidmail/astroid/actions/runs/26134040134/job/76865149422?pr=772#step:7:176

Can't reproduce locally, but maybe there's still missing initialisation?