Support Wayland natively

[duck-rh]

Bug Description

I'm running on Wayland with Sway 1.1. With GDK_BACKEND=wayland the application fails to start.

Steps to Reproduce

1. set GDK_BACKEND=wayland
2. run signal-desktop

Actual Result:

(signal-desktop:29858): Gtk-WARNING **: 18:23:33.657: cannot open display: :1

Expected Result:

All other GTK applications work fine on my system, so Signal should work too. Currently only the x11 backend works under Xwayland.

Platform Info

Signal Version: 1.25.1
Operating System: Debian sid
Linked Device Version: Android 7.1.2 (LineageOS 14.1)

[scottnonnenberg-signal]

Are you able to get Slack to work under Wayland? (basically, do other Electron apps support your scenario?)

[duck-rh]

@scottnonnenberg I do not use Slack and I don't think I have any other Electron app. So maybe the feature needs to be added there first but I have no idea.

[duck-rh]

It was already discussed here: electron/electron#9056

[WhyNotHugo]

I'd love to see this happen too. I'm trying to push people close to me to use something secure for IM, but the fact that Signal doesn't work on Wayland is a huge blocker (especially since it means a super blurry app on hidpi displays).

[genodeftest]

There is progress on getting Wayland support into Electron: electron/electron#10915

[WhyNotHugo]

It's most likely running via xwayland. The biggest issue here, is the lack of support for scaling (which is a must on highdpi displays). You get a blurred window -- it's rendered at normal size and then stretches the same way a png would look when stretched.

…

On Apr 19, 2020, at 13:37, Jan Vlug ***@***.***> wrote:  I'm a bit surprised by the statement that Signal does not work on Wayland. I'm using Fedora with GNOME Wayland and the Flathub Signal Desktop flatpak without any problems. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[ghost]

Quick bump on this issue - I was just last night able to get Signal Desktop running natively under Wayland. It requires a custom Electron build w/ the necessary Ozone configuration enabled, and shoehorning that custom Electron dist into Signal Desktop. If anybody is curious as to the process I used, or how I recommend repeating the process now (in hindsight), please do let me know. For the moment, it's well beyond the scope of a PR, until Electron decides to start shipping their standard builds with Ozone enabled by default... but it can be done.

[titaniumbones]

@ninefathom I would love to hear how you did it -- thanks so much for hte heads-up

[ghost]

@titaniumbones The main thing is getting a build of Electron with the necessary flags going. I followed their standard build instructions here, specifically for a release Linux build.

I also added patches from Arch's electron-ozone on AUR and used that as a starting point for gn build flags, since that happens to be the exact version of Electron which Signal Desktop currently needs. The patches were applied wholesale to my build tree before running gn. The flags to gn were slightly modified; here's what I ended up using (in addition to importing the release defaults):

    'blink_symbol_level = 0'
    'link_pulseaudio = true'
    'treat_warnings_as_errors = false'
    'use_gnome_keyring = false'
    'use_ozone = true'
    'ozone_auto_platforms = false'
    'ozone_platform_wayland = true'
    'ozone_platform_x11 = true'
    'use_xkbcommon = true'
    'use_system_libwayland = true'
    'use_system_minigbm = true'
    'use_system_libdrm = true'
    'use_glib = true'
    'use_gtk = true'
    'rtc_use_pipewire=true'

The main difference from that AUR PKGBUILD is that component ffmpeg seems to be needed for Signal Desktop; simple trial-and-error showed that it would no run correctly without it (just stalled at a blank blue window on launch).

Following that results in an Electron dist.zip which you can then shoe-horn into Signal Desktop. This has to be done in two places.

• First, get a local copy of the Node electron package @ version 8.2.5, extract your dist.zip into the dist directory for that package, set the environment variable ELECTRON_SKIP_BINARY_DOWNLOAD=1 so that npm doesn't try to download Electron from upstream, but uses your version in dist instead. Then edit Signal Desktop's package.json to point to that local Node electron package, e.g. "electron": "8.2.5" -> "electron": "file:///path/to/your/local/node/electron/package"

• Second, you need to override electron-builder's deep-seated desire to download a copy from upstream during the packaging stages. Why electron-builder doesn't just honor the package.json from Signal Desktop, I don't know, but it doesn't. It simply uses that to determine what version of Electron you want, then goes and fetches its own copy from upstream. Don't ask me why. Head to the package.json file for Signal Desktop, look for the "build:electron" line that invokes electron-builder and tack the following config flags on to it:
  --config.electronDist=/path/to/your/local/node/electron/package/dist --config.electronVer=8.2.5

Once you've done that, and after you've made any other local changes to Signal Desktop as needed- like working around all of the pre-compiled libraries in various dependencies to get build on aarch64 working, ahem Signal Desktop folks if you're reading- you can build Signal Desktop using the normal process, et voila! You get a package that will happily run natively on Wayland, no Xwayland needed. And then you sit around wondering if the 2-3 days it took to do that was really worth it.

If you're in a hurry and feeling brave, don't forget that you can skip building Signal Desktop locally... you can simply install or extract the normal, official Linux build, then unzip your custom Electron dist.zip over the top of it, and rename electron to signal-desktop. That's just part of the way Electron works; it'll happily pick up on Signal's resources/app.asar[.unpacked] and use them. I don't recommend doing this for official deployment, of course, but if you want to just test out signal-desktop on Wayland and want to cut out the second of the two steps above, it'll work.

[teutat3s]

Quick update for the interested following this - there are now experimental electron-nightly builds with runtime flags for wayland

electron --enable-features=UseOzonePlatform --ozone-platform=wayland

See this PR: electron/electron#26022 and the issue mentioned above

[Arxcis]

Update: The Electron 12 beta is available with npm i -g electron@beta-12-x-y, with support for the Ozone flags.

Demo

[WhyNotHugo]

Electron 12 is in beta, but will remain so until March.

Any chance that Signal builds can use the Electron beta until them? The lack of Wayland support is a pretty big dealbreaker for adopting Signal on modern Linux desktop.

[EvanHahn-Signal]

We are unlikely to release a version of Signal Desktop that depends on a prerelease version of Electron, as we don’t want to compromise the stability of the app. But we're keeping an eye on this—thanks for flagging and keeping this issue up to date.

[WhyNotHugo]

We are unlikely to release a version of Signal Desktop that depends on a prerelease version of Electron, as we don’t want to compromise the stability of the app.

This does sound weird.

Prerelease versions of electron make it run natively on Linux/Wayland desktop, and fixes a large pile of bugs (including security issues, like any unprivileged application being able to inspect all the contents of what Signal renders on screen).

Does this means that these bugs and security issues will remain part of signal for the next 4 months? :/

[EvanHahn-Signal]

First of all, I too am eager for the day that most of the world uses Wayland and would love for Signal Desktop to do its part. ("on abandoning the X server" is a nice read that informs this opinion.) But we're unlikely to upgrade to a prerelease version of Electron because of the potential instability a beta might bring. We've had some issues with this in the past.

Second, we're planning on upgrading from Electron v8 to Electron v11 soon. This doesn't address the issue because Wayland support seems to have landed in Electron v12, but the upgrade from 11 to 12 will be much smaller once it's out of beta. It should also address many of the bugs you alluded to.

Third, could you link us to that security issue?

[WhyNotHugo]

Any X11 application can grab what other images are X11 applications rendering.

So, a misbehaving application could potentially screengrab Signal's window and upload it elsewhere.

X11 provides no mechanism to prevent this.

[EvanHahn-Signal]

@WhyNotHugo Do we have any way to prevent this, other than completely dropping X11 support?

[WhyNotHugo]

I don't think so. AFAIK, that's one of wayland features, with isolation frameworks (e.g.: Flatpak) it's possible on wayland.

[Arxcis]

@EvanHahn-Signal I am happy that you are paying attention to this issue😁

It is of course totally OK to wait until Waland support becomes stable before using it in a stable Signal release👍

Maybe Signal could release wayland-support through a feature-flag before then? Example: flatpak run org.signal.Signal --enable-wayland

I realize this could be hard to maintain, but could be worth exploring though, as a way to get testing feedback from early adopters.

[EvanHahn-Signal]

Thanks for the suggestion—we'll keep that in mind.

[Arxcis]

Thanks for the suggestion—we'll keep that in mind.

Great😁

FYI, I just remembered that, to play nice with Flatpak, passing the proposed feature-flag as an environment variable is the preferred option - example SIGNAL_WAYLAND=true.

The reason for this is that Flatpak does not currently have a way to set extra-args permanently ref: flatpak/flatpak#2913, but one can easily set environment variables permanently per app.

[primeos]

tl;dr: First stable Electron 12 release: 2021-03-02 (but the actual release date could theoretically be adjusted)

Just as a quick FYI: https://www.electronjs.org/docs/tutorial/electron-timelines lists the stable release date for Electron 12 now:
2021-03-02 (based on Chromium M89 and Node.js v14.x; I guess all of this was already pretty certain but IIRC Electron 12 wasn't listed there some time ago).

(Note: This isn't meant to create pressure and I understand that Signal-Desktop will likely need (a bit) longer to update to Electron 12, especially since it's still based on Electron 8.5.2 and I'm not sure how the timeline for the transition to Electron 11 currently looks like, but I'm briefly dropping the release date here so that we don't risk forgetting about it.)

[EvanHahn-Signal]

@primeos Thanks for sending. We'll keep an eye on this.

I'm personally working on upgrading us to Electron 11, so hopefully the jump to 12 won't be so bad when it comes around.

[fosskers]

Electron 12 was just released: https://github.com/electron/electron/releases/tag/v12.0.0

[kaimast]

Note, that Electron does not seem to support drawing window decorations yet.
Signal either has to draw its own headerbar on Wayland or wait until that support has landed.

See these issues electron/electron#27522 electron/electron#27016 electron/electron#11907

[WhyNotHugo]

Note that most compositors will draw window decorations server-side, so electron apps don't really need to worry about that.

The only exception seems to be GNOME, which does not implement Server Side Decorations. GNOME devs have stated that they will not implement that either. GNOME users are likely used to seeing applications lacking decorations, since applications require dedicated GNOME support.

In the meantime, it's safe to ship with Wayland support as-is. Things like scaling will work on all compositors, and the only bugs visible will be already-known GNOME bugs. Meanwhile, the security benefits are substantial.

[EvanHahn-Signal]

I've filed an internal issue for us to upgrade to Electron 12.

To set expectations: upgrading to Electron 11, which we did recently, was arduous. This was likely more difficult because we upgraded from 8 to 11 (three major versions), but Electron upgrades can be challenging. We'll look into prioritizing this.

[puyoxyz]

The flatpak is missing wayland permissions

[genodeftest]

@puyoxyz wrote:

The flatpak is missing wayland permissions

That's the choice of the people building the flatpak, see flathub/org.signal.Signal#188

Please note that it is not sufficient to give wayland permissions to the signal flatpak, you still need to enable ozone using the command line.

flatpak run org.signal.Signal --enable-features=UseOzonePlatform --ozone-platform=wayland

This will change soon once the change making ozone the default (electron/electron#30814) will land in Signal when Signal rebases to this electron version.

Wayland support is still incomplete, as this command line results in a signal window without decorations on GNOME shell at least. More details in the issue linked above.

[genodeftest]

For the window decorations support, have a look at:

• [Feature Request] Support CSD in Wayland electron/electron#27522
• fix: Add support for Wayland window decorations electron/electron#29618

As a workaround, you could enable them following this comment.

[hgaiser]

Anyone else getting segfaults recently? I am pretty sure I had signal working on wayland before, but now I get:

$ signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland
Set Windows Application User Model ID (AUMID) { appUserModelId: 'org.whispersystems.signal-desktop' }
NODE_ENV production
NODE_CONFIG_DIR /usr/lib/signal-desktop/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME undefined
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/hgaiser/.config/Signal
config/get: Successfully read user config file
config/get: Successfully read ephemeral config file
making app single instance

(signal-desktop:24056): Gtk-WARNING **: 11:00:50.861: Theme parsing error: gtk-contained.css:2871:228: Missing closing bracket for :not()
[24108:0120/110051.072266:ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is egl, ANGLE is
{"level":30,"time":"2022-01-20T10:00:51.091Z","pid":24056,"hostname":"hostname","msg":"MainSQL: updateSchema:\n  Current user_version: 50;\n  Most recent db schema: 50;\n  SQLite version: 3.36.0;\n  SQLCipher version: 4.5.0 community;\n  (deprecated) schema_version: 254;\n"}
{"level":30,"time":"2022-01-20T10:00:51.095Z","pid":24056,"hostname":"hostname","msg":"app ready"}
{"level":30,"time":"2022-01-20T10:00:51.095Z","pid":24056,"hostname":"hostname","msg":"starting version 5.28.0"}
{"level":30,"time":"2022-01-20T10:00:51.096Z","pid":24056,"hostname":"hostname","msg":"media access status [object Undefined] [object Undefined]"}
{"level":30,"time":"2022-01-20T10:00:51.098Z","pid":24056,"hostname":"hostname","msg":"got fast spellcheck setting false"}
{"level":30,"time":"2022-01-20T10:00:51.099Z","pid":24056,"hostname":"hostname","msg":"getSystemTraySetting had no flags and did no DB lookups. Returning DoNotUseSystemTray"}
{"level":30,"time":"2022-01-20T10:00:51.099Z","pid":24056,"hostname":"hostname","msg":"Initializing BrowserWindow config: {\"show\":false,\"width\":1280,\"height\":1387,\"minWidth\":712,\"minHeight\":550,\"autoHideMenuBar\":false,\"titleBarStyle\":\"default\",\"backgroundColor\":\"#3a76f0\",\"webPreferences\":{\"devTools\":false,\"nodeIntegration\":false,\"nodeIntegrationInWorker\":false,\"contextIsolation\":false,\"preload\":\"[REDACTED]/preload.bundle.js\",\"nativeWindowOpen\":true,\"spellcheck\":false,\"backgroundThrottling\":false,\"enablePreferredSizeMode\":true},\"icon\":\"[REDACTED]/images/signal-logo-desktop-linux.png\",\"x\":0,\"y\":53}"}
[24056:0120/110051.100839:ERROR:cursor_loader.cc(114)] Failed to load a platform cursor of type kNull
zsh: segmentation fault (core dumped)  signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland

Running signal-desktop in lldb shows:

* thread #1, name = 'signal-desktop', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)

So somewhere a nullptr exception.

Running signal-desktop 5.28.0.

EDIT: Ah seems related to #5719 ..

[major-mayer]

Client side window decorations using GTK3 have been merged to Electron and backported to the new release 17.0.0 🥳 electron/electron#32650
So when Signal upgrades to Electron 17 window decorations should work even on Gnome.
That's not by default tho, you have to enable it with the argument --enable-features=WaylandWindowDecorations

[purew]

I just got a new GPU which enabled me to switch from X to Wayland (with sway as window-manager).

After this change, (no re-installation of the operating system), I get these errors about Missing X server

$ signal-desktop
Set Windows Application User Model ID (AUMID) { appUserModelId: 'org.whispersystems.signal-desktop' }
NODE_ENV production
NODE_CONFIG_DIR /usr/lib/signal-desktop/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME undefined
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/anders/.config/Signal
config/start: Did not find user config file (or it was empty), cache is now empty object
config/start: Did not find ephemeral config file (or it was empty), cache is now empty object
making app single instance
[2323343:0519/124804.273198:ERROR:ozone_platform_x11.cc(239)] Missing X server or $DISPLAY
[2323343:0519/124804.273224:ERROR:env.cc(255)] The platform failed to initialize.  Exiting.
The futex facility returned an unexpected error code.
fish: Job 1, 'signal-desktop' terminated by signal SIGABRT (Abort)

Is there anything I need to do to have signal start using Wayland? (I cleared the ~/.config/Signal path in case there was any kind of state there still specifying the older X server setup).

[faern]

@purew Try adding the argument --ozone-platform=wayland. I'm using the flatpak for Signal so can't promise it will work exactly the same. But that's in general how you tell an Electron based application to run in Wayland mode.

[purew]

@purew Try adding the argument --ozone-platform=wayland. I'm using the flatpak for Signal so can't promise it will work exactly the same. But that's in general how you tell an Electron based application to run in Wayland mode.

Oh wow, that actually worked, thanks!

[purew]

Curiously enough, the app then proceeds to SIGSEGV after linking to my phone

{"level":30,"time":"2023-05-22T15:08:12.830Z","msg":"Updating BrowserWindow config: %s {\"maximized\":false,\"autoHideMenuBar\":false,\"fullscreen\":false,\"width\":1276,\"height\":1546,\"x\":0,\"y\":0}"}
{"level":30,"time":"2023-05-22T15:08:12.830Z","msg":"config/set: Saving ephemeral config to disk"}
{"level":30,"time":"2023-05-22T15:08:12.830Z","msg":"config/set: Saved ephemeral config to disk"}
{"level":30,"time":"2023-05-22T15:08:33.283Z","msg":"Updating BrowserWindow config: %s {\"maximized\":false,\"autoHideMenuBar\":false,\"fullscreen\":false,\"width\":1916,\"height\":1546,\"x\":0,\"y\":0}"}
{"level":30,"time":"2023-05-22T15:08:33.284Z","msg":"config/set: Saving ephemeral config to disk"}
{"level":30,"time":"2023-05-22T15:08:33.284Z","msg":"config/set: Saved ephemeral config to disk"}
{"level":30,"time":"2023-05-22T15:08:54.854Z","msg":"App loaded - time: 43458"}
{"level":30,"time":"2023-05-22T15:08:54.854Z","msg":"SQL init - time: 339"}
{"level":30,"time":"2023-05-22T15:08:54.854Z","msg":"Preload - time: 336"}
{"level":30,"time":"2023-05-22T15:08:54.854Z","msg":"WebSocket connect - time: 42496"}
{"level":30,"time":"2023-05-22T15:08:54.854Z","msg":"Processed count: 0"}
{"level":30,"time":"2023-05-22T15:08:54.855Z","msg":"Messages per second: 0"}
fish: Job 1, 'signal-desktop --ozone-platform…' terminated by signal SIGSEGV (Address boundary error)

EDIT: I attempted to run via gdb to figure out more details, but when I do that, it works without any SIGSEGV:

gdb --args signal-desktop --ozone-platform=wayland
...

So might be some timing issue...

[genodeftest]

How about starting Signal with SIGNAL_USE_WAYLAND=1 environment variable instead? That works fine for me (using Signal flatpak)

[purew]

@genodeftest if that question is directed to me, then same behaviour:

env SIGNAL_USE_WAYLAND=1 signal-desktop
Set Windows Application User Model ID (AUMID) { appUserModelId: 'org.whispersystems.signal-desktop' }
NODE_ENV production
NODE_CONFIG_DIR /usr/lib/signal-desktop/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME undefined
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/anders/.config/Signal
config/get: Successfully read user config file
config/get: Successfully read ephemeral config file
making app single instance
[28919:0525/095645.857190:ERROR:ozone_platform_x11.cc(239)] Missing X server or $DISPLAY
[28919:0525/095645.857214:ERROR:env.cc(255)] The platform failed to initialize.  Exiting.
The futex facility returned an unexpected error code.
fish: Job 1, 'env SIGNAL_USE_WAYLAND=1 signal…' terminated by signal SIGABRT (Abort)

Seems like it still attempts to start with X using that procedure.

[chmanie]

For all coming here from google, this is how I can start Signal in wayland native (have a current electron version installed - I'm on 25.6.0):

electron --enable-features=UseOzonePlatform --ozone-platform=wayland /usr/lib/signal-desktop/resources/app.asar

[ZaneBartlett1]

@chmanie , I couldn't get that to work, I'm guessing that you do electron development and can use that run electron apps directly. I didn't want to get that set up, so here's my version. I'm using the Debian package downloaded using the instructions to install Signal from the Signal website. I'm also using Ubuntu 22.04.03 LTS with GNOME 42.9.

/opt/Signal/signal-desktop --use-tray-icon --no-sandbox %U --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations

If you use flatpak it would be something like this, although I didn't confirm this works.

flatpak run org.signal.Signal --use-tray-icon --no-sandbox %U --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations

Walking through it:

/opt/Signal/signal-desktop This is where my executable is since I used the signal website to download, this is different if you used flatpak, refer to command using flatpak run org.signal.Signal above.

--use-tray-icon This sets an tray icon, which I prefer, it has nothing to do with this issue

--no-sandbox %U This is the default from Signal, you can look into yourself if you'd like, per this comment though you should NOT remove it #5869 (comment)

--enable-features=UseOzonePlatform and --ozone-platform=wayland tell Signal to use Wayland, per flathub/org.signal.Signal#250 (comment)

--enable-features=WaylandWindowDecorations to enable GNOME headers on wayland for Signal, per #3411 (comment)

Problems I'm still having, and would like help with if anyone is experiencing them and figures out a fix:

• My cursor theme is not consistent to the rest of my system. It's typically a black cursor with a white outline and in Signal with this configuration, it's white with a black outline, as well as other weird changes similar to this.
• The Icon doesn't register correctly for my task bar. The icon does register correctly when I hit the super key and l look up signal
• The close, minimize, and delete are set to the left and not the right
• In general doing things like snapping the application to one side or using the header to drag it out of full screen will cause issues more often than if I don't run it with this configuration

Notes: If you're going to override the desktop file you'll want to know two things

• The desktop file is going to be in /usr/share/applications/signal-desktop.desktop. So you'd be updating your Exec= to

Exec=/opt/Signal/signal-desktop --use-tray-icon --no-sandbox %U --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations

• Signal will override this file every update, effectively ruining the configuration. What I have done to combat this is write a bash script that updates everything I need then runs sudo sed -i 's/Exec=\/opt\/Signal\/signal-desktop --no-sandbox %U/Exec=\/opt\/Signal\/signal-desktop --use-tray-icon --no-sandbox %U/g' /usr/share/applications/signal-desktop.desktop, which goes to the file, matches against the default desktop file, and then updates it to the correct updates. Note, I haven't updated this to include the flags added above. I personally don't think I'm going to keep this configuration right now as it's too unstable for my taste.
• Here is my entire upgrade bash script, including the above sed command, if it's helpful to anyone

# This is so that I can call a function for the alias upgrade-all, to automatically update my signal desktop to have a signal icon tray
function update-signal-desktop {
  sudo sed -i 's/Exec=\/opt\/Signal\/signal-desktop --no-sandbox %U/Exec=\/opt\/Signal\/signal-desktop --use-tray-icon --no-sandbox %U/g' /usr/share/applications/signal-desktop.desktop
}

# Let's me upgrade everything I need with a single command while also perseving a configuration with Signal not otherwise possible
alias upgrade-all="sudo apt-get update && sudo apt-get upgrade && sudo snap refresh && update-signal-desktop"

[Saroumane]

Thanks @ZaneBartlett1 you launch flags are very useful.
Maybe you can have your own permanent signal-desktop.desktop that does not get overwritten :

$ cp /usr/share/applications/signal-desktop.desktop ~/.local/share/applications
$ nano ~/.local/share/applications/signal-desktop.desktop 

I think desktop files in ~/.local/share/applications/ have priority over files (with the exact same name) in /usr/share/applications/

[ZaneBartlett1]

@Saroumane, thank you, I appreciate the recommendation and I have that recommended before, I also believe it would work. I don't really prefer that solution though, because then it puts updating the rest of the config myself in the future, which I don't want to do. A good example of this is that like I mentioned above, I'm not running that config I described because it's too unstable. When Signal does get around to officially moving everything to wayland though, if I were maintaining my own config I would need to follow and update that when they do. I'd prefer to just wait and have it happen when they push the updates. Granted if updates happen in the Exec= line, I would still be overriding it. Still not the best solution. I just wish they'd get the icon feature working like they've promised, now many years ago!

[chaserene]

as @ZaneBartlett1 explained above, there are numerous issues with the current "solution" that makes Signal run as a Wayland application. for me, it disables the tray icon. it's hard to consider this "native support", please reopen this issue.

[ZaneBartlett1]

@chaserene , just to make sure your comment is clear, when you say the tray icon are you referring to the left or the right image?

I personally do not have any issues getting the tray icon (image to the right) to populate correctly using --use-tray-icon, but I have issues running in wayland and getting the Signal desktop icon to be labelled correctly.

I'm assuming they're specifying the path to the desktop icon directly in the executable, and that isn't handled properly for when it's run as wayland. It's just a guess though, I have no confirmation of that. This is what it ends up looking like for me when it's run with /opt/Signal/signal-desktop --use-tray-icon --no-sandbox %U --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations

Can you confirm it disables your tray icon when using the flag or do you mean the desktop icon?

[ZaneBartlett1]

@chaserene also, I got turned around and assumed this was already open, but since this is a feature request, per this comment, it needs to be opened and considered in the Signal forum here - https://community.signalusers.org/search?q=wayland%20support. I don't actually see that anyone has opened it. If you (or anyone on the thread reading this in their email 😉 ) could open it that would be helpful. I'll open it later today if no one else does.

This post just has wayyyyyyyyyyyyyyyyyyyyyyyyy better SEO than their forum, so I figured I'd update this thread on my most current understanding of the solution at this time.

[ZaneBartlett1]

For everyone on the thread, I've gone ahead and reopened this feature request on the Signal forum here - https://community.signalusers.org/t/support-wayland-natively/58021. If you support this feature request, I believe the best thing to do at this point is heart that post.

[chaserene]

@ZaneBartlett1

Can you confirm it disables your tray icon when using the flag or do you mean the desktop icon?

yes, it disabled the tray icon for me, even though I started it with --use-tray-icon. my issue is not with the taskbar item -- IIRC that actually had the Signal icon displayed correctly, not a generic placeholder icon. I tried on GNOME with the official distribution (not Flatpak/Snap).

thank you a lot for opening the forum thread.

[mkurz]

Instead of

--enable-features=UseOzonePlatform --ozone-platform=wayland

(which works for me), you can also use:

--ozone-platform-hint=auto

[TheRedCyclops]

Currently testing on hyprland and the window does not appear when I use the flag --ozone-platform=wayland if the flag is not used signal will just run on xwayland, it seems like it is starting minimized because when using --use-tray-icon --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations it appears in the tray and I can open it from there

[mtnstar]

Currently testing on hyprland and the window does not appear when I use the flag --ozone-platform=wayland if the flag is not used signal will just run on xwayland, it seems like it is starting minimized because when using --use-tray-icon --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations it appears in the tray and I can open it from there

same over here, is there a way to start in maximized ?

edit: signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorat works for me without the tray icon and it directly starts maximized