Empty app_id under wayland

[ysooqe]

version
5.45.1

Problem
When starting signal-desktop under Wayland, the window itself does not have an app_id anymore (app_id=""). It used to be app_id="signal-desktop".
This prevents window-managers from executing app_id-specific actions (like for example focussing a window with a give app_id on a keybinding).

Steps to reproduce

1. $ signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland
2. read out the app_id of that window, e.g. using sway as a window manager: $ swaymsg -t get_tree and find that app_id: ""

Please let me know if I should provide any additional information.

[scottnonnenberg-signal]

We'll get this fixed when Electron fixes this: electron/electron#33578

[Altonss]

We'll get this fixed when Electron fixes this: electron/electron#33578

The upstream issue seems to have been fixed by electron/electron#34855 ;)

[pentamassiv]

This might also be the reason why the icon in the dash changes to the generic default icon after launching the application when using Wayland but not with XWayland.
As a workaround, you can rename /usr/share/applications/signal-desktop.desktop to /usr/share/applications/signal.desktop. I think that is a common problem with Electron applications.

[scottnonnenberg-signal]

We've updated to Electron 20 with recent builds - is this still happening?

[real-or-random]

This might also be the reason why the icon in the dash changes to the generic default icon after launching the application when using Wayland but not with XWayland.

Oh I thought the same but maybe that's a different issue. I see that issue also on v.5.59.0 which has Electron 20.1.0 which has the fix, see latest commit here https://github.com/electron/electron/blob/v20.1.0/shell/common/platform_util.h .

As a workaround, you can rename /usr/share/applications/signal-desktop.desktop to /usr/share/applications/signal.desktop. I think that is a common problem with Electron applications.

Apparently the app id is present again in recent released but it switched from "signal-desktop" to "signal" now. (@ysooqe are you sure it was "signal-desktop" previously?)

(If you change to StartupWMClass=signal in the .desktop file, this also works for me. But that's dangerous because different ids appear on X and on wayland etc, and different desktop environments handle this differently. I recently debugged something similar for Emacs and it was just a mess. The best is really to let desktop environments match via the file name of the .desktop file.)

[real-or-random]

Oh this may be just a packaging issue in Arch Linux. @pentamassiv Are you using Arch?

https://github.com/archlinux/svntogit-community/blob/packages/signal-desktop/trunk/signal-desktop.desktop

DesktopName is set correctly and according to electron/electron#34855 (comment) this is the right setting.
https://github.com/signalapp/Signal-Desktop/blob/main/package.json#L5

[pentamassiv]

Yes, I do use Arch. I am not sure I can follow you. The comment you linked basically says that WM_CLASS X window property, the application's .desktop file name and Wayland's app_id should all be the same, right?
Are you saying Arch needs to change https://github.com/archlinux/svntogit-community/blob/packages/signal-desktop/trunk/signal-desktop.desktop#L10 from StartupWMClass=Signal to StartupWMClass=signal-desktop?

[real-or-random]

Yes, X's WM_CLASS, wayland's app-id and the desktop file name should be the same. But what I say is that Arch should change the name of the desktop file to signal.desktop because I believe this is what the official package does according to

f790694#r36247568 , which has some history, see the discussion there.

edit: But I'm not entirely sure what the official packages does. I don't use Debian/Ubuntu, so I can't check it.

[scottnonnenberg-signal]

I'm going to close this, since it's about Arch and the modifications to Signal Desktop necessary to run on that platform, which we don't officially support. Please re-open if that's not correct.

[real-or-random]

I'm going to close this, since it's about Arch and the modifications to Signal Desktop necessary to run on that platform, which we don't officially support. Please re-open if that's not correct.

Sounds good but could you just tell us if the desktop file from the official release is signal.desktop or signal-desktop.desktop`? This would help us debug further.

[scottnonnenberg-signal]

This is the current configuration for our linux build assets:

Signal-Desktop/package.json

Lines 382 to 391 in b348bf9

	"linux": {
	"category": "Network;InstantMessaging;Chat",
	"desktop": {
	"StartupWMClass": "Signal"
	},
	"target": [
	"deb"
	],
	"icon": "build/icons/png"
	},

Also this:

Signal-Desktop/package.json

Line 5 in b348bf9

"desktopName": "signal.desktop",

[real-or-random]

Also this:

Signal-Desktop/package.json

Line 5 in b348bf9

"desktopName": "signal.desktop",

Oook but when inspect https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_5.59.0_amd64.deb, it contains signal-desktop.desktop and not signal.desktop.

So this may indeed a Signal bug. AFAIU the resolution of #3602 was to change the desktop file to signal.desktop in order to avoid the dash. Has this been reverted (by accident)?

[aacebedo]

Also seeing this bug on NixOS as the 6.1.0 package is based on the .deb. Is is possible to reopen this and change the name of the .desktop file?

[real-or-random]

I re-reported this as #6239