https://bugs.kde.org/show_bug.cgi?id=526701
Bug ID: 526701
Summary: On Wayland, windows get re-associated with the wrong
launcher after a ksycoca rebuild or a plasmashell
restart, because the executable name is matched
against StartupWMClass before the app_id is checked.
Classification: Plasma
Product: plasmashell
Version First 6.7.5
Reported In:
Platform: Arch Linux
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Task Manager and Icons-Only Task Manager widgets
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: 1.0
### Description
I run several Firefox profiles. Each has its own `.desktop` file and icon, and
each sets its Wayland app_id to the desktop file's basename. For example,
`FFWork.desktop`:
```
Exec=env MOZ_APP_REMOTINGNAME=FFWork firefox -P Work --name FFWork --class
FFWork %u
Icon=FFWork
StartupWMClass=FFWork
```
KWin reports these windows correctly. A KWin script shows
`resourceClass=FFWork` and `desktopFileName=FFWork`, while
`resourceName=firefox` (the executable basename, which KWin derives from
`/proc/<pid>/exe`).
When a profile is launched from its launcher, the Task Manager shows the custom
icon and a separate group. After any of the following, every profile window
switches to the stock Firefox icon:
- `kbuildsycoca6` runs (which happens on every pacman transaction that touches
desktop files)
- plasmashell is restarted. In this case every profile window is also merged
into a single "Firefox" group.
### Cause
In `libtaskmanager/tasktools.cpp`, `windowUrlFromMetadata()` (v6.7.5) does
these checks in order:
1. It matches `xWindowsWMClassName` against every service's `StartupWMClass`.
On Wayland this is the window's resourceName, which is the executable basename
(`firefox`).
2. Only if step 1 finds nothing does it match the appId against
`StartupWMClass`, and after that against `desktopEntryName()`.
The stock `/usr/share/applications/firefox.desktop` contains
`StartupWMClass=firefox`. As a result, step 1 matches every window whose
process is `/usr/lib/firefox/firefox`, and the exact app_id → `FFWork.desktop`
match is never reached. At launch the association is correct, because it comes
from the launch/activation context. It is lost whenever windows are re-resolved
through `windowUrlFromMetadata()` (`WaylandTasksModel` clears `appDataCache` on
`KSycoca::databaseChanged`).
### Evidence
- **Brave profiles are not affected.** Their executable is `brave`, and no
desktop file has `StartupWMClass=brave`.
- **A Firefox instance running as a different Unix user is not affected.** KWin
cannot read that process's executable path, so its resourceName is empty and
step 1 is skipped.
- **Removing the line fixes it.** With a user-local copy of `firefox.desktop`
that has the `StartupWMClass=firefox` line removed, the custom icons and groups
survive both `kbuildsycoca6 --noincremental` and a plasmashell restart.
### Steps to reproduce
1. Create `~/.local/share/applications/FFTest.desktop` with `Exec=firefox -P
Test --name FFTest %u`, a distinct `Icon=` and `StartupWMClass=FFTest`.
2. Launch it from the menu. The Task Manager shows the FFTest icon.
3. Run `kbuildsycoca6 --noincremental`.
**Actual:** the window switches to the stock Firefox icon. After `systemctl
--user restart plasma-plasmashell.service`, all such windows are grouped under
stock Firefox.
**Expected:** the window stays associated with `FFTest.desktop`, whose basename
equals the window's app_id exactly.
### Suggested fix
On Wayland, check for an exact `desktopEntryName() == appId` match (and
possibly `StartupWMClass == appId`) before matching the resourceName against
`StartupWMClass`. Alternatively, use the resourceName match only when nothing
matches the app_id. An app_id that exactly names an installed desktop file is
the most deliberate signal available. The executable basename is shared by
every instance and profile of a multi-profile application.
--
You are receiving this mail because:
You are watching all bug changes.
