[snap] StartupWMClass missing in .desktop file

Bug #1750243 reported by Jonas on 2018-02-18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Olivier Tilloy

Bug Description

Chromium Snap Version 64.0.3282.167

How to reproduce:

In Gnome:

Add the Chromium Snap to the left launcher panel.
Start the Chromium Snap.

Actual behavior:
The Chromium snap starts and creates a new symbol in the launcher panel.

Desired behavior:
The Chromium snap should start using the symbol which is already pinned to the launcher panel.

In Budgie:

The Chromium Snap cannot be pinned to the panel at all.

Possible solution:

Add StartupWMClass= ... to the .desktop launcher of the chromium snap.

Jonas (jonny-boy) on 2018-02-18
tags: added: snap
Olivier Tilloy (osomon) wrote :

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?

Changed in chromium-browser (Ubuntu):
status: New → Incomplete
Jonas (jonny-boy) wrote :


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

Jonas (jonny-boy) wrote :

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

Olivier Tilloy (osomon) on 2018-03-09
Changed in chromium-browser (Ubuntu):
status: Incomplete → New
Launchpad Janitor (janitor) wrote :

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

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
Samuel Kaiser (samuel-kaiser01) wrote :

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.

Olivier Tilloy (osomon) wrote :

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

Taqi Raza (mmtrt) wrote :

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

Olivier Tilloy (osomon) wrote :

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.

Changed in chromium-browser (Ubuntu):
assignee: nobody → Olivier Tilloy (osomon)
importance: Undecided → Medium
Olivier Tilloy (osomon) wrote :
Changed in chromium-browser (Ubuntu):
status: Confirmed → Fix Committed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers