Hello!

Thanks for the heads up.

The show: false is intentional, and we show the window when ready-to-show event happen. It sounds like it doesn't happen for you, which is concerning. However, I'm unable to reproduce it locally in either Ubuntu VM or on macOS. Can you reproduce it on either of officially supported platforms?

the problem seems to be that the ready-to-show event does not ever happen

pretty sure this only happens on electron 24 (and not on 23), while you still officially ship with electron 22, so I guess not

Unfortunately I can't reproduce it locally. Are you trying it with a packaged app, or with yarn start?

Unfortunately I can't reproduce it locally.

to be more exact, are you sure you're using electron24, and then also perhaps on wayland (--ozone-platform-hint=wayland, not sure if it's relevant)

if not, then it's not reproducible, as this was not a bug with 23.

Yup, I'm on 24.1.0, but testing on macOS and Ubuntu VM in github actions. I have a feeling that actions VM is not using wayland because we don't pass this argument. Can you reproduce this issue with just electron fiddle alone? Might be worth reporting to Electron!

yeah, sounds more related to electron in this environment then, unless there is a very good other reason the ready-to-show event is never emitted.

thanks for checking!

@selfisekai Did you get Signal to work with electron 23? I recall it showing an error box on startup when i tried and that's why i delayed 23 in openSUSE.

@brjsp we did not try

We'll be releasing a beta version based on Electron 24 soon; we'll see if that works for you.

Newly released 6.19.0 (which uses Electron 24.3.0) doesn't work with Wayland for me (Debian bookworm amd64), even though running signal-desktop with --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations worked fine until 6.18.1 (which used Electron 22.3.5), but now no window ever opens, just as described in this issue.

@roubert Can you tell us more about your configuration? A debug log would help as well!

I have a fairly standard Debian bookworm amd64 installation, using the default GNOME desktop enviroment on Wayland, with the only obvious non-standard thing being this additional --ozone-platform-hint=auto --enable-features=WaylandWindowDecorations passed to signal-desktop.

As the GUI never opens, I can't use the Debug Log / Submit feature, but I've now sent my logs per mail to support@signal.org as described here:

https://support.signal.org/hc/en-us/articles/360007318591-Debug-Logs-and-Crash-Reports

You can get a debug log straight from disk at ~/.config/Signal/logs

Yes, that is exactly what I did, just as described in that support page I linked to.

I've now updated to newly released 6.20.0 (which also uses Electron 24.3.0) and the problem persists (just as expected).

I think this ticket should be reopened. 6.20.1 still doesn't show a window under Wayland with Signal from Arch Linux's package or the deb from updates.signal.org. Forced to run 6.18.1.

Is Wayland supported/tested or should we expect issues?

Still broken in 6.22.0

Could you try 6.23.0-beta.1 ? It is on Electron 25.

Sure, but still no visible window with 6.23.0-beta.1, sorry.

Is Wayland supported/tested or should we expect issues?

I don't know whether Wayland is officially supported by Signal, but I also don't think that matters very much for this issue as more and more distros are switching to Wayland as the default and running Signal on native Wayland was something that used to work until the Signal 6.19.0 release and is something that will need to work again in the future.

It's also normal for even 6.18.1 to require multiple attempts until Signal starts without immediately crashing (#6247, #6260). When it doesn't crash immediately, it sometimes crashes when you start signal and send a message without waiting. Once it's been up for a minute or two, it's stable, so that's good.

@selfisekai this is probably a gtk/sway mismatch of the wayland protocols and what is expected, i.e. https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/150

if you built the qt5 shim for electron (assuming it supports it like chromium) and passed --enable-features=AllowQt it might then work by magic..

As the bug persists, can we reopen the ticket?

@scottnonnenberg-signal what do you think about adding --ozone-platform-hint=auto to default args? I don't have Xorg or Xwayland in my Wayland desktop and cannot confirm it works with X11, but I was able to drop the other two ozone flags in favor of this auto selection flag.

With the release of GNOME 45 this issue has suddenly become more important than it was before, as this release enables fractional scaling by default, which causes XWayland windows to appear a bit blurry, while native Wayland windows appear sharp (and correctly scaled), thereby making the ability to run Signal as native Wayland a much more important feature for many users from now on.

I can confirm the problem too. On a fresh install of Arch Linux with KDE, Wayland, and Intel graphics, if I install Signal Desktop with pacman -S signal-desktop and then launch it in a terminal with signal-desktop --ozone-platform-hint=auto, no window appears. But, once it gets to the point when the startup seems to be done, if I open another terminal and launch the application again just with signal-desktop (no arguments), the original window ends up launching with Wayland.

Thanks! That also did the trick for me.

Related

• feat: add support for ELECTRON_OZONE_PLATFORM_HINT env var electron/electron#39792

Also in Arch w/Wayland: signal-desktop --ozone-platform-hint=auto launches an instance in the background. However, unlike reported by @pgrete, launching a second signal-desktop instance fails with a quitting; we are the second instance, and the first instance subsequently crashes with a signal SIGSEGV (Address boundary error)

Signal works under xwayland.

Edit: signal-desktop 6.34.1-1

@scottnonnenberg-signal is it possible that this incorrectly labeled? "Upstream Change Needed" seems incorrect as from what I read here, we've not entirely determined why ready-to-show is not being sent/received. The xdg-activation issue is about clarification and the protocol itself seems to be primarily about focus and activation. The ready-to-show Electron documentation does not seem to indicate it would be related to Wayland specifics?

Is it possible to look into this issue again so we can get Signal running on Wayland? Perhaps the labels "Linux", "Wayland", and "Bug" more clearly indicate the scope of the issue.

Hi all, sorry for the issues you've been experiencing on Wayland. Appreciate all the work people have done on investigation and workarounds.

I'm running Debian + Wayland + Gnome and can confirm the bug -- the window doesn't show when running the app with either --ozone-platform-hint=wayland or --ozone-platform-hint=auto. This is a problem and we'll look into it.

@AndreasBackx Thank you for clarification and suggestions, I've updated the labels.

@ayumi-signal thank you for the quick reply! It seems like the label changes haven't gone through on my end. Could you have a second look?

Experiencing the same issue as #6368 (comment), both with "signal-desktop-fix-sway" and normal signal-desktop.

Error message: fish: Job 1, 'signal-desktop --enable-feature…' terminated by signal SIGSEGV (Address boundary error)

…which causes XWayland windows to appear a bit blurry, while native Wayland windows appear sharp (and correctly scaled)…

For me it’s vice versa. --ozone-platform=wayland yields a blurry window whereas the default is correctly scaled and sharp, but running through Xwayland, unfortunately.

Edit: Adding --force-device-scale-factor=2 (which happens to match my desktop’s actual scale factor) “fixes” the blurry text on Wayland and everything looks sharp, but the window is catastrophically broken. It maximizes into a quarter of the screen (half by half) and attempts to resize it cause it to jump around erratically. As if the mouse input location vs output location were badly misaligned. This is on Gnome (whatever the latest current Gnome is on ArchLinux, mutter 45.3-1) and with signal-desktop-fix-sway installed.

I'm experiencing the same issue as everyone, running it once in the terminal and a second time works fine, the window pops up.

To add to the confusion, I noticed that if I run signal-desktop using firejail, the window shows up on the first run.

When run through firejail, I have the following error in the terminal:

[13:0217/201659.684923:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/firejail/mnt/dbus/system: Permission denied

(It seems this error is emitted by the chromium sandbox)

I don't know anything about the inner working of Electron or how it interacts with the chromium sandbox, and maybe that error is not related at all, but could it be that Electron is waiting for a DBUS message that it never receives ? Hence the fact that it runs fine through firejail because apparently its access to DBUS is denied (and therefore probably fallback to another behavior).

I use Arch btw

The issue has recently resurfaced for me as an Arch Linux user with an Nvidia GPU.
There are no issues on my other machines using Intel GPUs.

My installation includes:

• wayland 1.22.0 with xorg-xwayland 23.2.4 (not used by Signal)
• nvidia 545.29.06
• signal-desktop 6.48.1

The issue appeared for me a month ago. Before that everything was working fine, albeit with visual artifacts, like flickering. I can't say, which update broke everything. If I were to bet, I would say it was Nvidia driver, which is constantly causing similar problems.

I managed to get Signal working "properly", i.e., without crashes or missing visual content.

I am leaving the instructions (that were already mentioned above) in a single comment, so that other people encountering the same problem could spare their time reading the whole thread. I did the following:

1. Install signal-desktop.
2. Install asar - a tool for extracting/packing Electron archives.
3. Create a temporary folder for storing the unpacked archive, named $TEMP_PATH.
4. Extract the asar archive:
   sudo asar extract /usr/lib/signal-desktop/resources/app.asar $TEMP_PATH
5. Open the file sudo vim $TEMP_PATH/app/main.ts.
6. Use / to search in vim for: const windowOptions.
   On a nearby line, replace show: false with show: true.
7. Repeat steps 5-6 for $TEMP_PATH/app/main.js!
8. Pack the archive back:
   sudo asar pack $TEMP_PATH /usr/lib/signal-desktop/resources/app.asar
9. (optional) Don't forget to remove the asar package and $TEMP_PATH folder.
10. Launch Signal using:
    signal-desktop --ozone-platform-hint=wayland --enable-features=OzonePlatform,WaylandWindowDecorations --disable-gpu --use-tray-icon

PSA for Arch Linux users: I made an AUR package signal-desktop-fix-sway that encapsulates @selfisekai’s show: true workaround.

When installed, it applies the workaround, and persists it across installs, reinstalls, downgrades, and upgrades of signal-desktop.

Uninstalling signal-desktop-fix-sway will undo the workaround.

@mkmaslov The signal-desktop-fix-sway package should automate steps no. 2 through 9 of your instructions.

The issue has recently resurfaced for me as an Arch Linux user with an Nvidia GPU. There are no issues on my other machines using Intel GPUs.
(snipped)

You machine might not have an issue, but I can confirm it's not a NVIDIA only issue.

I have an intel GPU, and the window doesn't appear under wayland, like described here above in this issue:

• I run signal-desktop --ozone-platform=wayland once: I have no window
• I run the same command a second time: I have a window appearing.
• I quit and rerun the same command: Window appearing.

I am running arch with signal-desktop package 7.6.0-1 (signal desktop 7.6.0).
I didn't patch the asar file.
I don't have anything set to make my window floating or not (it does not matter, same behaviour whether I have floating or not, first run is not working).

I am resolving the issue by running the command twice.

Hey, I have the same issue on NixOS with v7.11.1. Running under Wayland I need to execute the signal-desktop twice. I have an integrated intel GPU

The first instance keeps running but does not launch a window.

The second call logs some stuff and instantly closes, while the first instance now opens a window.

No issues on XWayland.

Set Windows Application User Model ID (AUMID) { AUMID: 'org.whispersystems.signal-desktop' }
NODE_ENV production
NODE_CONFIG_DIR /nix/store/i4r04ar10w9zgn4a6vwsbzqs7m3s1lva-signal-desktop-7.11.1/lib/Signal/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/nico/.config/Signal
config/get: Successfully read user config file
config/get: Successfully read ephemeral config file
making app single instance
quitting; we are the second instance

After upgrading to GNOME 46 today I thought revisiting this issue might be a good idea and it's still broken (still in the same way) with current Signal Desktop 7.17.0 and the trick of executing signal-desktop a second time ("quitting; we are the second instance") to get the first instance to show its window still works.

I'm on an Intel iGPU under Arch Linux and Sway. I have ELECTRON_OZONE_PLATFORM_HINT set to auto. Installing signal-desktop-fix-sway from the AUR worked for me. I wasn't experiencing this issue before in Hyprland where I have the same environment variable set, but I haven't tried recently. I usually use the flatpak package.

Issue also happening on AMD CPU + integrated GPU.

Was using a signal-desktop script to start using wayland backend.

#! /bin/sh

exec /usr/bin/signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland "$@"

Enabling Minimize to tray option shows that signal is indeed started by being in the systray.
Clicking it opens the main window.

Using signal-desktop-fix-sway fixes it.

Just sad that asar file cannot just be edited with a patch file so need many js dependencies to allow fixing it. (tried manually to check). But good work there on the fix in AUR.

Issue also happening on AMD CPU + integrated GPU.

Was using a signal-desktop script to start using wayland backend.

#! /bin/sh

exec /usr/bin/signal-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland "$@"

Enabling Minimize to tray option shows that signal is indeed started by being in the systray. Clicking it opens the main window.

Using signal-desktop-fix-sway fixes it.

Just sad that asar file cannot just be edited with a patch file so need many js dependencies to allow fixing it. (tried manually to check). But good work there on the fix in AUR.

Hello, you don't need to use your script to enable wayland support. you can use this env var
ELECTRON_OZONE_PLATFORM_HINT=wayland

use this env var
ELECTRON_OZONE_PLATFORM_HINT=wayland

This works but has the same problem of not showing a window on the first startup (and the window icon in GNOME activity overview being wrong).

use this env var
ELECTRON_OZONE_PLATFORM_HINT=wayland

This works but has the same problem of not showing a window on the first startup (and the window icon in GNOME activity overview being wrong).

Yes I know. I said "to enable wayland support". unrelated to the issue.
It's just a better way to enable wayland globally, better than use a custom script for each electron app :)