[snap] StartupWMClass missing in .desktop file

I cannot observe the issue on Ubuntu 18.04. I can pin the chromium snap icon to the launcher, both in the Ubuntu and GNOME sessions, and clicking that icon matches the newly-created window to the icon.

Which distribution/version are you running?

Solus

snap version
snap 2.30
snapd 2.30
series 16
solus 3
kernel 4.15.3-53.current

And Fedora (in VM)

snap 2.30-1.fc27
snapd 2.30-1.fc27
series 16
fedora 27
kernel 4.15.4-300.fc27.x86_64

Status changed to 'Confirmed' because the bug affects multiple users.

I've got the same issue in the Ubuntu 18.10 beta.

snap 2.35.4+18.10
snapd 2.35.4+18.10
series 16
ubuntu 18.10
kernel 4.18.11-surface-linux-surface

Also, Chromium's "Add shortcut..." function (which is broken in the Chromium snap, but the deb version does it as well) makes use of the StartupWMClass for Chromium extensions and web apps: `StartupWMClass=crx_okkolgldfknecfjnhhglfopimelbaceh`

And thus, when no "pure" Chromium window is opened but a Chromium web app is, opening Chromium will cause the Gnome shell to group the two icons under the name of the app (as it's the same executable without a distinguishable StartupWMClass, if I'm right).

With `StartupWMClass=chromium` added to /var/lib/snapd/desktop/applications/chromium_chromium.desktop it works as expected.

Note that the fact that "Create shortcut" doesn't work in the snap is a known issue: bug #1732482.

any update on this issue current version snap still does not include StartupWMClass have to manually add StartupWMClass=chromium in /var/lib/snapd/desktop/applications/chromium_chromium.desktop

I tested again, and while I can confirm that the chromium snap cannot be pinned to the favorite apps in a Fedora 29 VM without the "StartupWMClass=chromium" line in its desktop file, Ubuntu doesn't seem to be affected. I tested bionic and eoan, in the alternative gnome-session, which has defaults similar to Fedora.

I dug a bit in gnome-shell's code to try and understand why it's needed in Fedora and not in Ubuntu in the first place.

In get_app_from_window_wmclass():

  /* first try a match from WM_CLASS (instance part) to StartupWMClass */
  /* then try a match from WM_CLASS to StartupWMClass */
  /* then try a match from WM_CLASS (instance part) to .desktop */
  /* finally, try a match from WM_CLASS to .desktop */

The first two attempts will fail when there's no StartupWMClass.
The last two attempts would try to match, respectively, "chromium" (instance) and "Chromium" (class name) to a desktop file name. I'm not sure by which magic that would match against "chromium_chromium.desktop" (which is the name of the desktop file installed by the snap).

In this light, adding StartupWMClass to the desktop file looks correct, and won't hurt the existing matching logic on desktops where it already works.

Fixed with https://git.launchpad.net/~chromium-team/chromium-browser/+git/snap-from-source/commit/?id=02e1a3b458a1edef2307278880337e8e494d5569.