Created attachment 148150 [details] Search doesn't work nothing works SUMMARY *** The get new button in konsole shows behind the whole app and can't be interacted with searching does nothing *** STEPS TO REPRODUCE 1. In konsole right click and press Edit Current Profile go to Appearance and press ``Get New`` 2. Window should appear behind the whole app being completely unusable. 3. OBSERVED RESULT The **Get New** window can't be interacted at all nothing works EXPECTED RESULT The app should be able to search for color schemes or click on them SOFTWARE/OS VERSIONS Linux: openSUSE Tumbleweed (available in About System) KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION
I can confirm that happens on my 2 Arch Linux boxes with latest versions available in Arch repos
(In reply to Wojciech Janota from comment #1) > I can confirm that happens on my 2 Arch Linux boxes with latest versions > available in Arch repos This is the error Konsole gives when built from source (master branch): file:///usr/lib/qt/qml/org/kde/kirigami.2/templates/OverlaySheet.qml:219:38: QML FocusScope: Binding loop detected for property "contentItemMaximumWidth" QCoreApplication::postEvent: Unexpected null receiver file:///usr/lib/qt/qml/org/kde/kirigami.2/ApplicationItem.qml:151:9: QML Shortcut: Shortcut: Only binding to one of multiple key bindings associated with 13. Use 'sequences: [ <key> ]' to bind to all of them. file:///usr/lib/qt/qml/org/kde/kirigami.2/ApplicationItem.qml:147:9: QML Shortcut: Shortcut: Only binding to one of multiple key bindings associated with 14. Use 'sequences: [ <key> ]' to bind to all of them. file:///usr/lib/qt/qml/org/kde/kirigami.2/AbstractApplicationItem.qml:93: TypeError: Cannot read property 'position' of null file:///usr/lib/qt/qml/org/kde/kirigami.2/AbstractApplicationItem.qml:92: TypeError: Cannot read property 'background' of null When ran with valgrind it shows that something is referring to uninitialized memory: ==62328== at 0x7321E6F: ioctl (in /usr/lib/libc.so.6) ==62328== by 0x49BAD99: Konsole::Pty::setWindowSize(int, int) (Pty.cpp:97) ==62328== by 0x49BAA04: Konsole::Pty::init() (Pty.cpp:52) ==62328== by 0x49BA948: Konsole::Pty::Pty(QObject*) (Pty.cpp:37) ==62328== by 0x4A94512: Konsole::Session::openTeletype(int, bool) (Session.cpp:165) ==62328== by 0x4A9409D: Konsole::Session::Session(QObject*) (Session.cpp:134) ==62328== by 0x4ABE029: Konsole::SessionManager::createSession(QExplicitlySharedDataPointer<Konsole::Profile>) (SessionManager.cpp:103) ==62328== by 0x49DEB95: Konsole::ViewManager::createSession(QExplicitlySharedDataPointer<Konsole::Profile> const&, QString const&) (ViewManager.cpp:493) ==62328== by 0x488809F: Konsole::MainWindow::createSession(QExplicitlySharedDataPointer<Konsole::Profile>, QString const&) (MainWindow.cpp:504) ==62328== by 0x4879E8D: Konsole::Application::newInstance() (Application.cpp:191) ==62328== by 0x10E94A: main (main.cpp:228) ==62328== Address 0x1ffefff6d4 is on thread 1's stack ==62328== in frame #1, created by Konsole::Pty::setWindowSize(int, int) (Pty.cpp:85)
Can confirm, there is definitely sth. weird going on with the popups here. >When ran with valgrind it shows that something is referring to uninitialized memory: That is unrelated to the KNewStuff issues.
This broke due to the KNS Dialog being it's own window. I tried to check if gammaray finds sth. interesting, but with it everything works fine.
It looks like the KNS dialog is started with exec(), and Konsole's edit profile dialog is modal; but then closing the edit profile dialog and even the Konsole window, it looks like the KNS dialog is still bocked.
*** Bug 454088 has been marked as a duplicate of this bug. ***
Issue is QGuiApplicationPrivate::showModalWindow it marks every other non-modal window as blocked, including new windows. when we focus the new dialog at a wayland/X level Qt gets it, but in it's own internal dispatching ignores that and sends it to the modal window Qt is smart enough to handle child windows appropriately, but only if it knows about them. Having a transient parent should take care of this. We should have this anyway as that will fix some window placement bugs. Lazy fix: diff --git a/src/qtquickdialogwrapper.cpp b/src/qtquickdialogwrapper.cpp --- a/src/qtquickdialogwrapper.cpp +++ b/src/qtquickdialogwrapper.cpp @@ -11,6 +11,8 @@ +#include <QGuiApplication> +#include <QWindow> #include <KLocalizedContext> @@ -82,7 +84,13 @@ void QtQuickDialogWrapper::open() { if (d->item) { d->changedEntries.clear(); + + // unsafe Hack + auto win = qobject_cast<QWindow*>(d->item); + win->setTransientParent(QGuiApplication::focusWindow());; + // hack end + } } Should introduce a setTransientParent public API call? Or take the window in the ctor? Relying on the current focus is a bit horrible.
*** Bug 454224 has been marked as a duplicate of this bug. ***
*** Bug 454187 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/knewstuff/-/merge_requests/186
Git commit b634b65dd081746ccb8bdfa9bf2d878d13e2c0fb by Alexander Lohnau. Committed on 24/05/2022 at 10:58. Pushed by alex into branch 'master'. Fix QtQuickDialogWrapper dialog not being usable in konsole Patch provided by David Edmundson. ``` Issue is QGuiApplicationPrivate::showModalWindow it marks every other non-modal window as blocked, including new windows. when we focus the new dialog at a wayland/X level Qt gets it, but in it's own internal dispatching ignores that and sends it to the modal window Qt is smart enough to handle child windows appropriately, but only if it knows about them. Having a transient parent should take care of this. We should have this anyway as that will fix some window placement bugs. ``` M +7 -0 src/qtquickdialogwrapper.cpp https://invent.kde.org/frameworks/knewstuff/commit/b634b65dd081746ccb8bdfa9bf2d878d13e2c0fb
Mail sent to distributions ML about the fix, thanks!
Then I can cross that off my TODO list for today :)
*** Bug 451455 has been marked as a duplicate of this bug. ***
Isn't Bug 452751 a duplicate of this?
*** Bug 452751 has been marked as a duplicate of this bug. ***
(In reply to zocsfxljsgpmiuaanz from comment #15) > Isn't Bug 452751 a duplicate of this? Indeed, thanks for the hint.
Mid-air collision, anyway, fixed is fixed :)
*** Bug 454872 has been marked as a duplicate of this bug. ***
*** Bug 453672 has been marked as a duplicate of this bug. ***
*** Bug 455337 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/knewstuff/-/merge_requests/200
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/knewstuff/-/merge_requests/201