Signal-desktop: 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: https://github.com/electron/electron/issues/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 [e-mail] 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: https://github.com/electron/electron/pull/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: https://github.com/flatpak/flatpak/issues/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 https://github.com/electron/electron/issues/27522 https://github.com/electron/electron/issues/27016 https://github.com/electron/electron/issues/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.

[fosskers]

Thank you for your hard work!

[gothmog123]

is it in 5.0.0 beta? sorry

[EvanHahn-Signal]

@gothmog123 No, v5.0.0-beta still uses Electron 11.