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 [email protected] 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.

[scottnonnenberg-signal]

@nohsheef Why isn't it on by default? Seems that Chromium/Electron haven't changed the defaults for a reason, instead wanting to keep it opt-in. So it could perhaps be dangerous to always provide it?

[ghost]

I don't have sufficient insight into Chromium to answer that and, unfortunately, no X11 to test either because I run a pure Wayland (sway) desktop to avoid issues with a mixed environment. That auto hint flag has replaced the previous, explicit ozone backend selection for me and, going from the name, I assume it would transparently work the same way in X11 as well.

[maymage]

@nohsheef Why isn't it on by default? Seems that Chromium/Electron haven't changed the defaults for a reason, instead wanting to keep it opt-in. So it could perhaps be dangerous to always provide it?

The electron discussion is stuck with the same upstream argument. But Chromium is a full browser, Signal not. Staying with X11 means for wayland users to live with the defects of Xwayland, e.g.

https://bugs.chromium.org/p/chromium/issues/detail?id=1130919&sort=-modified&q=xwayland&can=2

So sure.. you may introduce problems with the =auto flag, but this comes at the price of exposing your wayland users to a bunch of Xwayland problems. What the pros and cons are, is for Signal to decide. Upstream considerations are a different beast.

[ghost]

6.25.0 still crashes frequently on start before it finally starts and stays running, but it's the first post-6.18.1 version that manages to show its window under Wayland.

But I'm back on 6.18.1 after 10 failed start attempts following a clean start, visible window, and exit. 6.18.1 started successfully on 1st attempt.

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