[education/rkward] rkward: Hack to fix Windows crash due to QWebEnginePage c'tor race condition

[Thomas Friedrichsmeier]

Git commit 3e485643bdde28beb4d5b95d766e658b6d1688b4 by Thomas Friedrichsmeier.
Committed on 05/12/2025 at 08:06.
Pushed by tfry into branch 'master'.

Hack to fix Windows crash due to QWebEnginePage c'tor race condition

M  +1    -0    rkward/main.cpp
M  +13   -0    rkward/rkward.cpp

https://invent.kde.org/education/rkward/-/commit/3e485643bdde28beb4d5b95d766e658b6d1688b4

diff --git a/rkward/main.cpp b/rkward/main.cpp
index 740511772..d8b9c7f26 100644
--- a/rkward/main.cpp
+++ b/rkward/main.cpp
@@ -146,6 +146,7 @@ int main(int argc, char *argv[]) {
 		qputenv(chromiumflags, "--no-sandbox --single-process --enable-features=NetworkServiceInProcess");
 	}
 #endif
+
 	// annoyingly, QWebEngineUrlSchemes have to be registered before creating the app.
 	QWebEngineUrlScheme scheme("help");
 	scheme.setSyntax(QWebEngineUrlScheme::Syntax::Path);
diff --git a/rkward/rkward.cpp b/rkward/rkward.cpp
index da8cd950d..a4042a248 100644
--- a/rkward/rkward.cpp
+++ b/rkward/rkward.cpp
@@ -180,7 +180,20 @@ RKWardMainWindow::RKWardMainWindow() : KParts::MainWindow() {
 	RKComponentMap::initialize();
 
 	// stuff which should wait until the event loop is running
+#if defined(Q_OS_WIN)
+	// HACK FIXME
+	// This is a very bad workaround around a very hideous QtWebEngine bug on Windows. Surfaced for us with the switch to Qt 6.9:
+	// crash in the QWebEnginePage c'tor, if that is invoked too soon after start *and* application was not started from the
+	// command line (making debugging insanely frustrating). Very obviously some lazy-loading mechanism is breaking, but again,
+	// this is clearly *inside* the QWebEnginePage c'tor, i.e. not something missing in our side of the initialization.
+	// RKWard may (or may not) open HTML windows as part of the post init, and so we delay this a bit. 400 ms was the minimum delay
+	// suggested by my testing, so I'm going for a bit more to be on the safe side, hopefully.
+	// Note that the performance hit is not quite as bad, as the backend startup is the heaviest part, and that is already running
+	// in parallel.
+	QTimer::singleShot(1000, this, &RKWardMainWindow::doPostInit);
+#else
 	QTimer::singleShot(0, this, &RKWardMainWindow::doPostInit);
+#endif
 }
 
 RKWardMainWindow::~RKWardMainWindow() {