https://bugs.kde.org/show_bug.cgi?id=450342
--- Comment #4 from Nicolas Fella <[email protected]> --- Oh this is a fun one. Here's what happens: - Kwin/overview use KIO::ApplicationLauncherJob to launch the app - ApplicationLauncherJob finds that the target supports DBus activation - ApplicationLauncherJob notices we are on Wayland and requests an XDG activation token: https://invent.kde.org/frameworks/kio/-/blob/master/src/gui/kprocessrunner.cpp#L313. It connects the token arriving to launching the app - Further down it sets which app should be launched: https://invent.kde.org/frameworks/kio/-/blob/master/src/gui/kprocessrunner.cpp#L320 - Further down it starts the app when we are not waiting for a token: https://invent.kde.org/frameworks/kio/-/blob/master/src/gui/kprocessrunner.cpp#L343 So far so good. So why does it fail only in kwin_wayland? Usually the token arrives asynchronously, so the app is already set and it launches fine. However, in KWindowSystem::requestXdgActivationToken there is a check for KWindowSystemPrivateV2, and if that fails it directly emits xdgActivationTokenArrived: https://invent.kde.org/frameworks/kwindowsystem/-/blob/master/src/kwindowsystem.cpp#L819 This makes the token arrival no longer async and all the slots are triggered directly (since it's not a queued connection), which leads to the app being launched before m_service is set. boom -- You are receiving this mail because: You are watching all bug changes.
