com.google.Chrome.desktop - StartupWMClass about com.google.chrome

[refi64]

Adding StartupWMClass=google-chrome to the .desktop file doesn't change how PWAs are handled as it is only defining what should be grouped with it in the case that the .desktop name doesn't match the WM_Class and doesn't force it onto the program.

The behavior of StartupWMClass is very strange and non-standard across compositors, and GNOME Shell also has its own logic specifically for Flatpaks that might give out very weird results. (This also all gets weirder with native Wayland windows...) I'll probably just have to do testing on multiple systems to make sure nothing actually breaks...

Worth noting that the original Elementary OS issue was a bug in libwnck that was fixed.

[wjt]

Another option is to run Chrome with --class=com.google.Chrome.

Could you try removing that local desktop file, then running:

flatpak run com.google.Chrome --class=com.google.Chrome

and see if that also addresses your issue?

[N0VERCL0CKER]

I believe if we do that it's going to break our PWA install support... That may not be needed but isn't really an option for now.

I've seen some other bugs about this on eOS, and from some basic research, I think it's a bug in bamf/libwnck? I'll figure out the rest of the details and try to fix it at the "source" there.

Adding StartupWMClass=google-chrome to the .desktop file doesn't change how PWAs are handled as it is only defining what should be grouped with it in the case that the .desktop name doesn't match the WM_Class and doesn't force it onto the program. Any PWA being grouped with the main window is because chrome is including google-chrome WM_Class along with the unique WM_Class for the PWA so it will group them with chrome and other PWAs until that is fixed. You check this by installing a PWA and check by running xprop WM_CLASS and then clicking on the window to see what is listed under the WM_CLASS. It also can be noted that the official chrome install from google has the shortcut named google-chrome.desktop so any program with the google-chrome WM_Class would link to it the same as having StartupWMClass=google-chrome in it would.

For anyone wanting to fix it on their system you can copy the .desktop file from /var/lib/flatpak/app/com.google.Chrome/current/active/export/share/applications to ~/.local/share/applications open it in a text editor and add StartupWMClass=google-chrome under [Desktop Entry]

[robxu9]

I wanted to chime in on this - without StartupWMClass=Google-chrome on GNOME 41, after launching Chrome, the startup notification keeps spinning until it times out. If I set --class=com.google.Chrome, it still spins unless I put StartupWMClass=com.google.Chrome in the desktop file as well, which makes me suspect that because it's omitted from the desktop file, the startup notification just doesn't know about it.

[refi64]

I believe if we do that it's going to break our PWA install support... That may not be needed but isn't really an option for now.

I've seen some other bugs about this on eOS, and from some basic research, I think it's a bug in bamf/libwnck? I'll figure out the rest of the details and try to fix it at the "source" there.

[rdrms]

This also affects KDE. With the default .desktop file provided, you cannot add the Chrome Flatpak to the "Icons Only Task Manager", it seems the task manager is not associating the window with the desktop file. Seems to have a similar problem to GIMP, where if you pin the application, the window opens up under another icon.

Running "flatpak run com.google.Chrome --class=com.google.Chrome" does work, but if you pin it when it's running (the options are available here), close it, and then reopen using the icon... it shows under a new icon. Really annoying.

[Dansito]

I have the same problem in KDE wayland, any solution?

[mpanhans]

Do advise if any help can be provided testing this on the various systems. If things do not break, it would be useful to have for several desktop environments.

[chenzhiwei]

The Telegram .desktop file works fine in KDE Wayland: https://github.com/flathub/org.telegram.desktop

[nicolasfella]

PWAs get their own desktop files with their own StartupWMClass, so adding StartupWMClass to the main desktop file shouldn't break anything.

There was a bug in Plasma's task manager code that might have been triggered by this, but that has been fixed: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2219

[vipierozan99]

I had a similar problem on Ubuntu and Fedora Silverblue, where if you run chrome on wayland (ozone-platform=wayland) the PWAs don't get the correct App id and are treated by gnome as Chrome windows, instead of Gmail, Google Calendar, etc..

[solecram]

Hello, this probem is solved? I keep having problems of the duplicate icons in task manager of plasma. Apparently it just happening of Chrome flatpak.

[tazihad]

This problem still exist in Fedora 39 KDE flatpak version of chrome.