If I am reading source properly, the fault seems to be in XdgActivationV1Integration::requestToken() in xdgactivationv1.cpp:
Particulary following code:

QString XdgActivationV1Integration::requestToken(bool isPrivileged, SurfaceInterface *surface, uint serial, SeatInterface *seat, const QString &appId)
{
...
    if (const QString desktopFilePath = Window::findDesktopFile(appId); !desktopFilePath.isEmpty()) {
        KDesktopFile df(desktopFilePath);
        Window *window = Workspace::self()->activeWindow();
        if (!window || appId != window->desktopFileName()) {
            const auto desktop = df.desktopGroup();
            showNotify = desktop.readEntry("X-KDE-StartupNotify", desktop.readEntry("StartupNotify", true));
        }
        icon = QIcon::fromTheme(df.readIcon(), icon);
    }
...
}

The Window::findDesktopFile(appId) returns .desktop file if it exists, otherwise returns application filepath. However no further check if it is actual desktop file is made and KDesktopFile object is created with the non-desktop file and accessed as such which triggers parsing of binary file.

This would explain why creating even empty .desktop file for the app fixes the issue, however I am not sure why I did not encountered the issue until now as the code seems to be several years old. Possibly there are new ways to reach this execution path in the recent KDE version? Nevertheless this appears to be genuine bug as binary file is handled like .desktop file.

Good investigation!

> This would explain why creating even empty .desktop file for the app fixes the issue, however I am not sure why I did not encountered the issue until now as the code seems to be several years old. Possibly there are new ways to reach this execution path in the recent KDE version?
Not sure either, maybe there were some changes in KDesktopFile or KConfig that made the issue worse.

Anyways, do you want to make a MR to fix this, or should I do it? Replacing the isEmpty() check with KDesktopFile::isDesktopFile should be enough to fix it afaict

Created attachment 173356 [details]
Window::iconFromDesktopFile returns only .desktop file

>> Anyways, do you want to make a MR to fix this, or should I do it? Replacing the isEmpty() check with KDesktopFile::isDesktopFile should be enough to fix it afaict

Just to be sure, I've checked the other places where Window::findDesktopFile is used, and there is one other place where similar/same bug might be triggered - Window::iconFromDesktopFile which is called either by X11Window::getIcons and WaylandWindow::updateIcon

QString Window::iconFromDesktopFile(const QString &desktopFileName)
{
    const QString absolutePath = findDesktopFile(desktopFileName);
    if (absolutePath.isEmpty()) {
        return {};
    }

    KDesktopFile df(absolutePath);
    return df.readIcon();
}

As such, wouldn't be better to correct Window::findDesktopFile behavior to make sure only proper .desktop file or empty string? This way it would also help any new code in the future using this function to expect proper data. Something like attached diff (it just simply does the same check as KDesktopFile::isDesktopFile before returning)

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/6418

Git commit f3f2a338d42c18fe2ad8d8175eb2328501be4d51 by Vlad Zahorodnii.
Committed on 19/09/2024 at 11:35.
Pushed by vladz into branch 'master'.

Locate desktop files more carefully

It may happen that the specified app id is a file path to a binary file.
In which case, the findDesktopFile() function will return that file path
and KConfig will try to parse a binary file.

On other hand, the findDesktopFile() function should ideally always
append the ".desktop" suffix. If there's no file with such a file name,
nothing should be returned. But due to some Qt applications providing app
ids with the ".desktop" suffix, the findDesktopFile() function also tries
to find a desktop file without appending the ".desktop" suffix. However,
the fallback code doesn't actually try to verify that the desktop file
name contains the ".desktop" suffix, which can result in the
findDesktopFile() function providing values that it shouldn't. In this
case, returning the file path to a binary executable.

M  +19   -12   src/window.cpp

https://invent.kde.org/plasma/kwin/-/commit/f3f2a338d42c18fe2ad8d8175eb2328501be4d51

Git commit 7797f2b22d76ec8c07e4003bc88c335215a63710 by Vlad Zahorodnii.
Committed on 19/09/2024 at 11:50.
Pushed by vladz into branch 'Plasma/6.2'.

Locate desktop files more carefully

It may happen that the specified app id is a file path to a binary file.
In which case, the findDesktopFile() function will return that file path
and KConfig will try to parse a binary file.

On other hand, the findDesktopFile() function should ideally always
append the ".desktop" suffix. If there's no file with such a file name,
nothing should be returned. But due to some Qt applications providing app
ids with the ".desktop" suffix, the findDesktopFile() function also tries
to find a desktop file without appending the ".desktop" suffix. However,
the fallback code doesn't actually try to verify that the desktop file
name contains the ".desktop" suffix, which can result in the
findDesktopFile() function providing values that it shouldn't. In this
case, returning the file path to a binary executable.


(cherry picked from commit f3f2a338d42c18fe2ad8d8175eb2328501be4d51)

Co-authored-by: Vlad Zahorodnii <vlad.zahorodnii@kde.org>

M  +19   -12   src/window.cpp

https://invent.kde.org/plasma/kwin/-/commit/7797f2b22d76ec8c07e4003bc88c335215a63710