[plasma/discover/Plasma/6.7] /: DiscoverObject: Address quitting with concurrent KJobs

Git commit 0d0a1d35c715838f585590d54a1a9d5b14cbd151 by Oliver Beard.
Committed on 15/08/2026 at 14:11.
Pushed by olib into branch 'Plasma/6.7'.

DiscoverObject: Address quitting with concurrent KJobs

We have a mechanism that disables random eventloops (KJobs) from
quitting Discover outside of the user's interaction (see
QCoreApplication::setQuitLockEnabled in discover/main.cpp).

It so happens that we would at times have KJobs running also _after_
Discover's window closes. See how on the reported bugs they often
describe it happening early in the startup process.

This patch restores the Q*Application::quitLockEnabled property so that
once Discover is with its task and we let go and QCoreApplication can
let these jobs finish and eventually quit.

It changes the DummyBackend to issue a KJob at the start to be able to
reproduce this problem and eventually its fix.

BUG: 497419
BUG: 522245
BUG: 522815
BUG: 518264


(cherry picked from commit a8b5538958594d90406aa0294d3934bcd06e7607)

Co-authored-by: Aleix Pol <[email protected]>

M  +2    -0    discover/DiscoverObject.cpp
M  +22   -0    libdiscover/backends/DummyBackend/DummyBackend.cpp

https://invent.kde.org/plasma/discover/-/commit/0d0a1d35c715838f585590d54a1a9d5b14cbd151

diff --git a/discover/DiscoverObject.cpp b/discover/DiscoverObject.cpp
index 39edd0606..a41220246 100644
--- a/discover/DiscoverObject.cpp
+++ b/discover/DiscoverObject.cpp
@@ -558,6 +558,7 @@ void DiscoverObject::reconsiderQuit()
     }
 
     m_sni.reset();
+    QCoreApplication::setQuitLockEnabled(true);
     // Let the job UI to finalise properly
     QTimer::singleShot(20, qGuiApp, &QCoreApplication::quit);
 }
@@ -596,6 +597,7 @@ bool DiscoverObject::eventFilter(QObject *object, QEvent *event)
         if (!quitWhenIdle()) {
             return true;
         }
+        QCoreApplication::setQuitLockEnabled(true);
     }
     // } else if (event->type() == QEvent::ShortcutOverride) {
     //     qCWarning(DISCOVER_LOG) << "Action conflict" << event;
diff --git a/libdiscover/backends/DummyBackend/DummyBackend.cpp b/libdiscover/backends/DummyBackend/DummyBackend.cpp
index 37375c490..91078ccd7 100644
--- a/libdiscover/backends/DummyBackend/DummyBackend.cpp
+++ b/libdiscover/backends/DummyBackend/DummyBackend.cpp
@@ -15,6 +15,7 @@
 
 #include <KAboutData>
 #include <KConfigGroup>
+#include <KJob>
 #include <KLocalizedString>
 #include <KPluginFactory>
 #include <KSharedConfig>
@@ -26,6 +27,24 @@ DISCOVER_BACKEND_PLUGIN(DummyBackend)
 
 using namespace Qt::StringLiterals;
 
+// Use KJob to track initialisation to match how KNS would
+// It helps to identify issues when Discover closes
+class DummyBackendInitializationJob : public KJob
+{
+public:
+    explicit DummyBackendInitializationJob(QObject *parent)
+        : KJob(parent)
+    {
+    }
+
+    void start() override
+    {
+        QTimer::singleShot(3000, this, [this]() {
+            emitResult();
+        });
+    }
+};
+
 DummyBackend::DummyBackend(QObject *parent)
     : AbstractResourcesBackend(parent)
     , m_updater(new StandardBackendUpdater(this))
@@ -33,6 +52,9 @@ DummyBackend::DummyBackend(QObject *parent)
     , m_fetching(true)
     , m_startElements(120)
 {
+    auto initializationJob = new DummyBackendInitializationJob(this);
+    initializationJob->start();
+
     QTimer::singleShot(500, this, &DummyBackend::toggleFetching);
     connect(m_reviews, &DummyReviewsBackend::ratingsReady, this, &AbstractResourcesBackend::emitRatingsReady);
     connect(m_updater, &StandardBackendUpdater::updatesCountChanged, this, &DummyBackend::updatesCountChanged);