Bug 501267

I find two warnings/errors in KDevelop output when the freeze happens:
kf.kirigami.platform: Failed to find a Kirigami platform plugin for style "Fusion"
file:///usr/lib/qt6/qml/org/kde/kirigami/templates/private/DrawerHandle.qml:117:5: TypeError: Cannot read property 'width' of null

The UI thread always has the following uninformative call stack:
#0 ??() at /usr/lib/libc.so.6
#1 ??() at /usr/lib/libc.so.6
#2 ??() at /usr/lib/libc.so.6
#3 ppoll() at /usr/lib/libc.so.6
#4 ??() at /usr/lib/libglib-2.0.so.0
#5 g_main_context_iteration() at /usr/lib/libglib-2.0.so.0
#6 QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)() at /usr/lib/libQt6Core.so.6
#7 QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>)() at /usr/lib/libQt6Core.so.6
#8 QCoreApplication::exec()() at /usr/lib/libQt6Core.so.6
#9 main() at /home/Fast_storage/kdevelop-kf6/app/main.cpp:835

The background parsing continues, and even the background parser progress bar keeps moving, reaches 100% and disappears. So the UI thread is not frozen, but user input (mouse clicks and typing) is ignored. After some more experiments, I see that Quick Open works more or less (can be activated by a shortcut and handles mouse clicks). Other keyboard shortcuts, such as Ctrl+Tab, work too. Seems like there is an invisible modal window that blocks input to the main KDevelop window.

A merge request with a fix is welcome at https://invent.kde.org/kdevelop/kdevelop/-/merge_requests

The following patch for knewstuff/src/widgets/button.cpp fixes this bug for project templates and for Qt Help documentation:
-            dialog.reset(new KNSWidgets::Dialog(configFile, q));
+            dialog.reset(new KNSWidgets::Dialog(configFile));

The passing of a parent to KNSWidgets::Dialog() is the only significant difference between KNSWidgets::Button and KNSWidgets::Action. And the Action does not cause freezes, e.g. in Kate/KDevelop Snippets plugin. I'll check other apps that use KNSWidgets::Button and maybe create a knewstuff merge request.

The above patch does not fix the file templates crash reported in Bug 504104 though.

Reproduced the same mouse input freeze in KDevelop (Project=>New from Template...=>Get More Templates), KDevelop (Settings=>Configure KDevelop...=>Templates=>Get More Templates on either Project Templates or File Templates tab), KDevelop (Settings=>Configure KDevelop...=>Documentation=>Qt Help=>Get New Documentation), K3b (Settings=>Configure K3b...=>Themes=>Get New Themes...), Parley (Download New Collections...), KLettres (File=>Get Alphabet in New Language...) and KsirK (New Local Game=>Download New Skins...) under Xfce. Only KDevelop and K3b are affected under Plasma (no matter Wayland or X11).

Only uses of KNSWidgets::Button, not KNSWidgets::Action, are affected. But not all of them - many KDE apps use KNSWidgets::Button but never freeze. One of KDevelop's own uses of KNSWidgets::Button (File=>New From Template=>Get More Templates...) never freezes (but crashes because of an unrelated Bug 504104). And I don't see any code difference that might explain why. Maybe it somehow depends on the top-level (window) widget ancestor of the KNSWidgets::Button.

KLettres uses KNSWidgets::Dialog directly, passes the application main window as the dialog parent.

When the mouse input freeze happens in KDevelop or K3b, a workaround is to use keyboard shortcuts to show any other dialog. Mouse input works normally afterwards.

Parley, KLettres and KsirK freeze completely - do not respond neither to mouse nor keyboard input. But pressing the Escape key restores normal responsiveness. Furthermore, unlike KDevelop and K3b, clicking the KNSWidgets::Button works correctly and perfectly after the Escape key press, though only until the application is restarted.

Not passing KNSWidgets::Button as the parent of KNSWidgets::Dialog works around all the freezes except for the one in 
KLettres, which does not use KNSWidgets::Button, and therefore requires a custom workaround.

But KDevelop still freezes eventually when different KNSWidgets::Button instances are clicked multiple times under Xfce. The parent dialog does not disappear and the keyboard navigation workaround does not work in this case though. And the backtrace is very different, so this is probably another unrelated bug:
#0 0x00007f0958eade22 in ??? () at /usr/lib/libc.so.6
#1 0x00007f0958ea1fda in ??? () at /usr/lib/libc.so.6
#2 0x00007f0958ea2024 in ??? () at /usr/lib/libc.so.6
#3 0x00007f0958f1c05e in poll () at /usr/lib/libc.so.6
#4 0x00007f0949d2220b in ??? () at /usr/lib/libxcb.so.1
#5 0x00007f0949d2429b in xcb_wait_for_special_event () at /usr/lib/libxcb.so.1
#6 0x00007f089563d68f in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#7 0x00007f089563d889 in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#8 0x00007f08956406c9 in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#9 0x00007f0895640aab in loader_dri3_get_buffers () at /usr/lib/libgallium-25.0.5-arch1.1.so
#10 0x00007f0895642e74 in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#11 0x00007f0895642f2c in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#12 0x00007f08956398d6 in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#13 0x00007f08956e7e68 in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#14 0x00007f08956e8ab1 in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#15 0x00007f0895639498 in ??? () at /usr/lib/libgallium-25.0.5-arch1.1.so
#16 0x00007f089563d143 in driBindContext () at /usr/lib/libgallium-25.0.5-arch1.1.so
#17 0x00007f08a8977238 in ??? () at /usr/lib/libGLX_mesa.so.0
#18 0x00007f08a897c3a6 in ??? () at /usr/lib/libGLX_mesa.so.0
#19 0x00007f095c0bae83 in ??? () at /usr/lib/libGLX.so.0
#20 0x00007f095c0c1d81 in ??? () at /usr/lib/libGLX.so.0
#21 0x00007f08a80d10fb in ??? () at /usr/lib/qt6/plugins/xcbglintegrations/libqxcb-glx-integration.so
#22 0x00007f08a80d2c55 in ??? () at /usr/lib/qt6/plugins/xcbglintegrations/libqxcb-glx-integration.so
#23 0x00007f095a70f332 in QOpenGLContext::create() () at /usr/lib/libQt6Gui.so.6
#24 0x00007f095a71dd09 in QRhiGles2InitParams::newFallbackSurface(QSurfaceFormat const&) () at /usr/lib/libQt6Gui.so.6
#25 0x00007f095a41b380 in QBackingStoreRhiSupport::create() () at /usr/lib/libQt6Gui.so.6
#26 0x00007f095ad3d06c in QWidgetPrivate::create() () at /usr/lib/libQt6Widgets.so.6
#27 0x00007f095ad3bdf6 in QWidget::create(unsigned long long, bool, bool) () at /usr/lib/libQt6Widgets.so.6
#28 0x00007f095ad4eaa4 in QWidgetPrivate::setVisible(bool) () at /usr/lib/libQt6Widgets.so.6
#29 0x00007f095af8a308 in QDialogPrivate::setVisible(bool) () at /usr/lib/libQt6Widgets.so.6
#30 0x00007f095b34cf27 in KNSWidgets::Dialog::open (this=0x55eccdc072a0) at knewstuff-6.14.0/src/widgets/dialog.cpp:119
#31 0x00007f09595b6cc9 in ??? () at /usr/lib/libQt6Core.so.6
#32 0x00007f095ae20e1b in ??? () at /usr/lib/libQt6Widgets.so.6
#33 0x00007f095ae21318 in ??? () at /usr/lib/libQt6Widgets.so.6
#34 0x00007f095ae310ee in QAbstractButton::mouseReleaseEvent(QMouseEvent*) () at /usr/lib/libQt6Widgets.so.6
...

A possibly relevant merge request was started @ https://invent.kde.org/frameworks/knewstuff/-/merge_requests/364

*** Bug 505220 has been marked as a duplicate of this bug. ***

Git commit 4e711ba080361561c7b2c212dad92ba98dbfa2a1 by Igor Kushnir.
Committed on 20/10/2025 at 18:51.
Pushed by igorkushnir into branch 'master'.

Don't make KNSWidgets::Button the parent of KNSWidgets::Dialog

Clicking some instances of KNSWidgets::Button in KDevelop and K3b fails
to open the KNSWidgets::Dialog, closes the dialog that contains the
button after a few seconds, and leaves the application UI unresponsive
to mouse input. Keyboard navigation and shortcuts keep working. Showing
any other dialog via keyboard shortcuts makes mouse input work in the
application again.

Clicking a KNewStuff button in Parley, KLettres and KsirK also fails to
open the KNSWidgets::Dialog and makes the application UI unresponsive to
both mouse and keyboard input. Pressing the Escape key restores normal
responsiveness. This second bug occurs under Xfce but not under KDE
Plasma.

Many other instances of KNSWidgets::Button in KDE applications work
correctly for some reason. The few KNSWidgets::Action instances that I
have tested are unaffected by such bugs. More details about the issues
described above can be found in my comments under the linked bug report.

The passing of a parent to KNSWidgets::Dialog() is the only significant
difference between the management of a KNSWidgets::Dialog instance by
KNSWidgets::Button and KNSWidgets::Action. This commit eliminates the
difference and thereby works around both input responsiveness bugs
described above except in KLettres. That's because KLettres uses
KNSWidgets::Dialog directly rather than KNSWidgets::Button, and
therefore requires a custom workaround.

KNSWidgets::Button stores its instance of KNSWidgets::Dialog in a
unique_ptr. Therefore the now parentless dialog is still destroyed along
with the button. The absence of a parent may affect the location of the
dialog, but I think that the difference is not very important.
FIXED-IN: 6.20

M  +1    -1    src/widgets/button.cpp

https://invent.kde.org/frameworks/knewstuff/-/commit/4e711ba080361561c7b2c212dad92ba98dbfa2a1

*** Bug 511896 has been marked as a duplicate of this bug. ***