Bug 443252

Summary:	WM_CLASS not respected all the time on Plasma Wayland
Product:	[Plasma] kwin	Reporter:	Srevin Saju <srevinsaju>
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED NOT A BUG
Severity:	normal	CC:	nate, nicolas.fella
Priority:	NOR
Version First Reported In:	5.22.90
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Srevin Saju 2021-10-03 11:10:17 UTC

SUMMARY

Not sure if this is a duplicate

WM_CLASS is not respected by launchers and icon task view. Launchers having
different WM_CLASS are grouped together into one app icon, for example, a Chromium PWA with WM_CLASS is grouped under a single icon "Chromium", but this
used to work on X11. Tested with Plasma X11 and GNOME Wayland, works on both.  

STEPS TO REPRODUCE
1. Create a desktop file, in `~/.local/share/applications/youtube-music-pwa.desktop`
```
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=YouTube Music
Exec=/usr/bin/chromium --profile-directory=Default --app="https://music.youtube.com"
Icon=youtube-music
StartupWMClass=music.youtube.com
```

2. Use Plasma X11, use the Application Launcher to search for "youtube music" and open using the desktop launcher. It should open up with a separate icon (you can try another icon in the desktop file, for example: okular to test the changes if you don't have youtube-music icon)
3. Use Plasma Wayland, and it can be noticed that the icons are having chromium's logo instead of the specified youtube music logo.


OBSERVED RESULT
The icons are grouped together on Plasma Wayland

EXPECTED RESULT
The icons should be separate, respecting the `WM_CLASS` attribute of the window.


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Comment 1 Vlad Zahorodnii 2021-10-04 12:07:25 UTC

Is chromium running with native wayland support?

Comment 2 Nate Graham 2021-10-04 22:28:36 UTC

Comment 3 Bug Janitor Service 2021-10-19 04:35:47 UTC

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Comment 4 Srevin Saju 2021-10-19 04:47:01 UTC

Apologize for the delay, I have these in my chromium flags (~/.config/chromium-flags.conf).
```
--enable-features=UseOzonePlatform
--ozone-platform=wayland
```
Does this look correct? Or am I missing any other chromium flags?

Comment 5 Vlad Zahorodnii 2021-10-19 06:53:12 UTC

StartupWMClass doesn't work with native wayland clients. Also, I'm not sure that there are any plans to add support for it on wayland. It has to be agreed upon by other desktop environments and gui toolkits.

Comment 6 Srevin Saju 2021-10-19 06:55:21 UTC

Oh okay, I was confused if its a bug in kwin wayland because it works on GNOME wayland (the icon is represented correctly). I haven't tried any other clients though.

Comment 7 Vlad Zahorodnii 2021-10-19 06:58:27 UTC

Well, GNOME Shell is a bit special beast. Both the compositor and the desktop shell run in the same process, it could have some magic internal wm_class mapping logic.

Comment 8 Vlad Zahorodnii 2022-01-19 20:02:42 UTC

Regarding chrome, there was an attempt to make it set reasonable app id on wayland. https://chromium-review.googlesource.com/c/chromium/src/+/3383817

If you use firefox, you could pass custom `-name` argument, e.g. https://gist.github.com/zzag/e2f0a5e022b726466c29afa3d497a3fc

From the compositor side, there's nothing that we can do.

Comment 9 Nicolas Fella 2022-01-19 21:36:41 UTC

> StartupWMClass doesn't work with native wayland clients. 
> From the compositor side, there's nothing that we can do.

There is a legitimate (and somewhat unrelated) bug on our side, which is that the taskmanager ignores WM_CLASS for XWayland windows. See https://bugs.kde.org/show_bug.cgi?id=447845