Wayland: does not show window without a patch on newer electron versions

[selfisekai]

just a heads-up for you. I'm the maintainer of the signal-desktop package in alpine linux.

coincidentally 2 things happened at once, so I'm not sure which one was the problem, but I'm guessing the former:

• upgrade of electron to 24
• upgrade of signal-desktop to 6.13.0 (well, an attempt)

with both these changes, the window of signal-desktop stopped appearing for me.

it shows correctly with this patch:

--- ./app/main.ts.orig
+++ ./app/main.ts
@@ -721,7 +721,7 @@
   const titleBarOverlay = await getTitleBarOverlay();
 
   const windowOptions: Electron.BrowserWindowConstructorOptions = {
-    show: false,
+    show: true,
     width: DEFAULT_WIDTH,
     height: DEFAULT_HEIGHT,
     minWidth: MIN_WIDTH,

log: https://s3.sakamoto.pl/lnl-shit/Ad6QacHk03dQ.txt

[indutny-signal]

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?

[selfisekai]

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

[indutny-signal]

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

[nekopsykose]

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.

[indutny-signal]

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!

[nekopsykose]

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!

[brjsp]

@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.

[selfisekai]

@brjsp we did not try

[scottnonnenberg-signal]

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

[roubert]

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.

[scottnonnenberg-signal]

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

[roubert]

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

[scottnonnenberg-signal]

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

[roubert]

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

[roubert]

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

[ghost]

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.

[ghost]

Is Wayland supported/tested or should we expect issues?

[ghost]

Still broken in 6.22.0

[indutny-signal]

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

[ghost]

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

[roubert]

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.

[ghost]

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.

[nekopsykose]

@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..

[ghost]

As the bug persists, can we reopen the ticket?

[ghost]

@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.

[claui]

I tried the patch and it just seg faults when I move the mouse. Although it's not consistent. When my mouse was not over the window and I moved it into the window, it actually stayed open.

Same for me.
Without the workaround, the window doesn’t appear at all. With the workaround, the window appears and the app (v6.27.1) is fully usable with the keyboard. But as soon as I move the mouse inside the window’s client area, the app segfaults 99 % of the time. Same thing when I resize the window through some other means.

[cbzeller]

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.

Just want to add as a data point, I was experiencing this issue on hyprland and your patch fixed it. Thanks!

[ghost]

I had to update to 6.28.0 yesterday after Signal declared 6.18.1 unsupported and read-only.

Findings:

• 6.28.0 with --ozone-platform-hint=auto and without show: true patch does show a window.
• Intermittent startup crashes are frequent, usually less than 10 attempts.
• During one of the startup attempts, it crashed more than 31 times and then I had to clean /tmp, because the filesystem was full and nothing would start anymore.
• Configuring sway to float Signal fixes the startup crash for me. Found the workaround here: Nightly (using electron 25.1.x) crashes on launch on wayland (sway) element-hq/element-desktop#1026 (comment)

Sway workaround for Signal startup crash:

for_window [app_id="signal"] floating enable

[ghost]

Floating the Signal window by default (rule above) has fixed all crashes for me. 6.29.0 also works.

[gtkramer]

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.

[gtkramer]

Checking the debug log of Signal when it launches with XWayland, this is my system info:

App version: 6.30.2
Environment: production
Node version: 18.15.0
OS version: #1 SMP PREEMPT_DYNAMIC Wed, 13 Sep 2023 08:37:40 +0000
Time: 1695005876727
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Signal/6.30.2 Chrome/114.0.5735.289 Electron/25.8.1 Safari/537.36

Checking the about for VSCode, I see that it's reporting the same Electron version. If this is true, then I'm wondering why Signal has this problem. Adding --ozone-platform-hint=auto to "${HOME}/.config/code-flags.conf" does the right thing for VSCode.

[roubert]

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.

[pgrete]

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.

[maymage]

Related

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

[pescepalla]

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

[AndreasBackx]

@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.

[ayumi-signal]

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.

[AndreasBackx]

@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?

[vars1ty]

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)

[andrejpodzimek]

…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.

[ShellCode33]

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

[mkmaslov]

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

[claui]

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.

[evrardjp]

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.

[Nydragon]

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 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.

Second run logs

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