Pinned apps in the dock opens in a separate dock icon

I’ve been seeing this issue around since GNOME 40 (Fedora 34). Some apps (for example VirtualBox, VSCodium or Firefox), even if they are pinned in the dock, open in a duplicate icon on the dock, and there is no app name in the top bar, just “Unknown application”. Initially, I thought that the reason was in Dash to Dock, but resetting or disabling it doesn’t affect this, since in the standard dock I get the same behavior. Flatpack apps and default GNOME apps behave just fine.
2021-12-11 10-28-57

Interestingly, everything works on a clean installed system. Tried to reset dconf /org/gnome but didn’t help.

hi @proninyaroslav Welcome.
I suppose you do use Workstation?
Do you use gnome-extensions?

1 Like

Yes, F35 + GNOME 41 with Dash to Dock. I tried using Dash to Dock on a clean system and it works fine. In my case, both Dash to Dock and the default dock don’t work as expected. These apps are labeled unknown.

If you have not, maybe try a new user to see if the problem exists there as well?

1 Like

@grumpey
Yes, the same thing. Very strange.

1 Like

Please check in folder /usr/share/applications and find any *.desktop of your app that behave strange.

Check that file let’s say the-app.desktop with file the-app.desktop. If the file is symbolic link to other file in different folder, then the behavior is normal.

It also true if the app placed in /usr/local/share/applications or in /home/username/.local/share/applications it will behave like what you experience.

My understanding if there any file *.desktop not placed in /usr/share/applications directly, most likely it will behave like that.

I think this is not my case. I even created a new user to check it. So, the user’s configs don’t affect this problem in any way. One pattern I’ve noticed is that all of these applications only support X11 and run in Wayland. They use WM_CLASS, but for some reason, editing StartupWmClass in the .desktop file does not affect the WM_CLASS of the window, which I get from xprops. Probably this problem is somewhere in the system I would not want to reinstall the system, but so far this is the only option. I will be grateful if you can give any hints.

xprops values for example:
WM_CLASS(STRING) = "vscodium", "VSCodium"

WM_CLASS(STRING) = "VirtualBox Manager", "VirtualBox Manager"

I managed to figure out something: GNOME Shell internally uses iconv to convert between Latin-1 and UTF-8 encoding to handle the WM_CLASS window (which is responsible for identifying X11 applications, including in Wayland). As it turned out LATIN1 is missing on my system, the iconv -l command doesn’t return it. Is it possible to somehow fix this by adding the encoding without system resinstallation?

UPD: After some research, it turned out that the solution is much simpler than I expected: after the latest package upgrading in the /usr/lib64/gconv/ dir the new gconv-modules.rpmnew file appeared which contained LATIN1. After renaming it and running the iconvconfig command, everything worked fine.

2 Likes

Thanks for sharing, that’s an interesting fix.

1 Like