Webapp icons and window titles not working correctly in GNOME on Wayland

[Kasui92]

I'm experiencing issues with web applications created using Omakub's webapp installer when running GNOME Shell on Wayland. The webapps function correctly in terms of launching and running, but they don't integrate properly with the desktop environment.

The Problem

When I install a webapp (for example, using omakub-webapp-install X https://x.com /path/to/icon.png), the application launches fine but has two significant visual issues in the GNOME interface:

First, the dock and overview don't show the custom icon I provided during installation. Instead, all webapps display the generic gear/cog icon that GNOME uses as a fallback when it can't find the proper application icon.

Second, the application name in the dock appears as something like chrome-twitter_Default or chrome-chatgpt_Default instead of showing the clean name I specified (like "Twitter" or "ChatGPT"). This auto-generated naming makes it confusing to identify which webapp is which, especially when multiple webapps are open.

What I've Tried

I've attempted several approaches to fix this issue, all without success:

I tried placing icons in the standard FreeDesktop directories at ~/.local/share/icons/hicolor/256x256/apps/ and using just the icon name without a full path in the desktop files, similar to how system applications work. This approach didn't help and actually broke some system icons temporarily until I reverted the changes.

I experimented with the StartupWMClass field in the desktop files, matching it to the --class parameter passed to Chromium. The theory was that GNOME would use this to associate the Chromium window with the correct desktop file, but it didn't make any difference in practice.

I added Wayland-specific flags to the Chromium launch command, including --ozone-platform=wayland and --enable-features=UseOzonePlatform, thinking the issue might be related to how Chromium communicates with Wayland compositors. This also had no effect.

I tried setting the CHROME_DESKTOP_FILE environment variable before launching Chromium, hoping it would help GNOME identify which desktop file corresponds to the application window. Again, no improvement.

I ensured that icon filenames don't contain spaces and that the icon cache is properly updated using gtk-update-icon-cache. The icons are valid PNG files and display correctly when viewed directly, so the files themselves aren't corrupted.

My Understanding of the Issue

After all these attempts, I believe the core problem is that Chromium generates its own internal window identifiers when running in app mode, and these don't match what we're trying to tell it via command-line parameters. On X11, GNOME could use various X properties to associate windows with desktop files, but Wayland's security model is more restrictive and doesn't expose the same information.

The --class parameter we pass to Chromium should set the window class that GNOME uses for identification, but it appears that either Chromium isn't honoring this parameter correctly on Wayland, or GNOME Shell isn't able to use this information in the way it did on X11.

Looking for Solutions

I'm wondering if anyone has successfully implemented Chromium-based webapp launchers on GNOME Wayland that show proper icons and application names. Are there alternative approaches I haven't considered?

Is there a GNOME Shell extension or DBus interface that could help bridge this gap? Or are there undocumented Chromium flags that improve Wayland integration for app mode?

Any insights into how this could be resolved while keeping the simple launcher approach would be greatly appreciated. The goal is to maintain a straightforward webapp installation process without requiring complex wrapper scripts for each individual application.