[snap] No separate icon/window tracking for app launchers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
chromium-browser (Ubuntu) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
I've created a custom chromium launcher for an internal website, starting chromium in --app mode.
The launcher should get it's own Gnome dash icon.
To match the created windows to the dash icon, I've taken the following measures:
- include "StartupWMClass
- gave chromium the "--class=myfoo" parameter to make it set it's WM_CLASS to myfoo
I've verified the WM_CLASS to be properly set to myfoo using xprop.
However, this does not work when chromium is launched via snap.
All windows get attributed to the chromium dash icon no matter what their WM_CLASS is.
Bypassing snap and launching chromium via /snap/chromium/
Here are the full chromium exec lines:
Broken:
Exec=chromium --class=myfoo --no-first-run --app=https:/
Working:
Exec=/snap/
This is on a fully patched 20.04 system.
description: | updated |
tags: | added: snap |
Changed in chromium-browser (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Medium |
summary: |
- [snap] Gnome dash window tracking is broken when using chromium snap + [snap] No separate icon/window tracking for app launchers |
Possibly related.
To handle Spotify GUI size I created a custom spotify.desktop for my user in order to scale the GUI for high DPI monitor and the Application is duplicated in the launcher.
The WM_CLASS is correctly configured, I just copied the original .desktop file and modified the 'Exec' line. Also verified value using `xprop WM_CLASS` command.
Even though both files match with Application name and WM_CLASS the snap's version is always present. Is not an issue as I just favorite my version... previously when installing Spotify from a .deb file this worked flawlessly.
Might be an issue in when the a snap '.desktop' are imported vs traditional imports.