[Bug Report] Chromium WebApps display generic fallback gear icon in Wayland due to StartupWMClass / app_id mismatch

[Hermann-91]

[Bug Report] Chromium WebApps display generic fallback gear icon in Wayland due to StartupWMClass / app_id mismatch

Environment

• OS: Zorin OS 17/18 / Linux Mint (Wayland session)
• Desktop Environment: GNOME Shell / Zorin Desktop
• Application: webapp-manager (Ice SSB)
• Browser: Google Chrome / Chromium (Ozone platform: Wayland)

---

Steps to Reproduce

1. Open WebApp Manager.
2. Create a new WebApp using Google Chrome (or Chromium/Brave) pointing to https://music.youtube.com/.
3. Select an icon (custom or preset) and save.
4. Add the WebApp to Favorites / Dash.
5. Launch the WebApp.

---

Expected Behavior

The running window should group under the pinned WebApp launcher on the dock/taskbar with its designated icon.

---

Actual Behavior

The running window fails to group with the launcher and appears as a separate taskbar entry displaying a generic gear ("carenagem") placeholder icon.

---

Root Cause Analysis

1. Wayland app_id Generation in Chromium:
   When running under Wayland (--ozone-platform=wayland), Chromium ignores the command line switch --class=WebApp-<name><id>.
   Instead, Chromium calculates the Wayland surface app_id via shell_integration_linux using the pattern:
   chrome-<host>__<path>-<profile> (e.g. chrome-music.youtube.com__-Default).

2. Launcher Mismatch:
   webapp-manager writes:

   StartupWMClass=WebApp-MusicGoogle7059

   Because StartupWMClass does not match the Wayland app_id, the window manager (GNOME Shell / Mutter) cannot link the surface to the .desktop file and falls back to a generic window icon.

---

Proposed Fix

In webapp-manager launcher generation logic for Chromium-based browsers:

1. Parse the WebApp URL to compute the expected Wayland app_id:

   from urllib.parse import urlparse
   parsed = urlparse(url)
   host = parsed.netloc or parsed.path
   wayland_app_id = f"chrome-{host}__-Default"

2. Set StartupWMClass directly to the calculated wayland_app_id (chrome-<host>__-Default) instead of WebApp-<codename>.
   • Note on Best Practice: Do not create a secondary symlink like <wayland_app_id>.desktop in ~/.local/share/applications/, as doing so causes desktop environments (e.g. GNOME / Zorin Menu) to index and display duplicate application entries in the app launcher. Setting StartupWMClass alone is 100% sufficient for GNOME Shell / Mutter to map the surface window to the single existing .desktop launcher.
3. Ensure the icon asset is copied to ~/.local/share/icons/hicolor/<size>/apps/ under the wayland_app_id name so the window manager reliably resolves it.