Consider providing a build for Wayland

[LongChair]

• Electron version: any
• Operating system: Linux

Expected behavior

Latest Ubuntu comes with Wayland a default display server.
On embedded devices, wayland provides usually the best rendering performance, at least compared to X11 where the performance is usually pretty poor.

Actual behavior

Current linux / arm / arm64 binary releases are great but run pretty bad from my experience on embedded devices. They all link to libx11 / gtk which makes them unusable for wayland.

libGtk can be build with --wayland-backend and then electron can be built against it

I would really like electron team to consider providing prebuilt binaries usable with wayland, that would open a new range of possibilities, especially on embedded devices.

[LongChair]

After reading a bit, it looks like the best way to achieve this would be to enable ozone in the chromium build. So I wanted to know if someone ever did that or if i could get a few pointers to try it out ?
Also are there any other parts of electron that would have strong X11 dependencies ? GTK3 shouldn't at this point but wondering if things like brightray have ?

[LongChair]

Further look in the build shows that electron depends on chromium libgtkui.
The libgtkui in chromium has kinda strong dependencies on X11 and will not builds on anything else than X11 / OSX / Win at this point.

I'm not sure what libgtkui in chromium is used for (that's not in libgtk3).
it looks like its for creating status icons and app indicators.
I wonder if it would be possible to make that optional...

[LongChair]

I have managed to patch libchromiumcontent to make it build without X11.
This required quite a few patches and is not really suitable.

libchromiumcontent can be built in that case with use_aura=true use_ozone=trueand some more parameters. for more details see my patches here https://github.com/LongChair/libchromiumcontent/commits/upgrade-to-chromium-61

Then I started the electron build and the situation is similar. Although most of the code has some #if defined(USE_AURA) parts, it clearly cannot be build for aura with ozone at this point even though libgtk3ui would not depend on it.

There are also bits in the brightray GYP files that make it X11 dependent, a wayland version would need there to link with the right displaymanager libs (wayland-client, ...) .

I believe that the best way to make it buildable without too much hassle on linux and without X11 support, would be to make the libgtk3ui component use optionnal in the build. But I don't know electron enough to know what this would break / make unavailable. it seems it's mostly taskbar icons, which wouldn't matter much as there is no taskbar in weston anyways :)

I guess i'll stop my attempt here as that makes too many patches and there has been no interest / feedback on this from electron team at this point :)

[admiral0]

This would allow running via a hack on ChromeOS as well.

[MarshallOfSound]

This would allow running via a hack on ChromeOS as well.

That has piqued my interest a bit, can you explain how that would work?

[admiral0]

Latest chromeos devices, the ones that bundle android runtime use wayland to display non-chrome apps.

I have sucessfully compiled and run a hello wayland demo.

[LongChair]

ChromeOS uses Aura & Ozone, either with Wayland or GBM/KMS.
Still the issues mentionned above are the same. libgtkui is still the major issue for making a build, both within chromium & electron.

[onny]

Nice progress @LongChair !
I was also looking into that but prefered to test Chrome (Chromium) for Wayland first. I guess that the V8 engine is the biggest part for migration, both in Chrome and Electron.
Igalia has a chromium fork which is close to upstream: https://github.com/Igalia/chromium
Maybe we can integrate the Igalia patches into your Electron build?
Well, I haven't been able to run Chromium on Wayland yet ...

[onny]

I was able to compile and run chromium with wayland patches! See the build script here: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=chromium-wayland-git

[LongChair]

@onny : well as i meantionned before, it seems that a lot of X11 dependencies are still in electron itself because if the use of libgtkui in the libcc build.

As far as i have seen electron also handles AURA as a build parameter but then assumes that aura/x11 is used. so there is not way currently to get it to build without X11.

it will run on Xwayland / Wayland but this is far from bringing the wayland performance, especially on embedded.

[onny]

Oh that is interesting:

Electron is now using GTK3 in the master branch, will be shipped in next minor/major release.
#2927 (comment)

👍

[LongChair]

@onny : yes that is what chromium 61 brings. this is progress.

What i'm looking for is a full native wayland version of electron as X11 (Xwayland) tends to take the overal performance down by a bunch.
For this there are two issues, even if Chromium builds and runs on native wayland, this is whthout libgtkui afaik. that dependency that libcc is adding to chromium build itself seems to be severely depending on X11 at this point.
Then aside chromium, electron code itself relies both on libcc:gtkui, but also on a bunch of X11 functions which are not available on native wayland.

I am not sure how that X11 dependency could be overcome. The following things would be required :

• Get rid in electron of the licbc gtkui need. ? if not possible then have chromium make it X11 / Wayland compatible
• Get rid of the X11 mandatory dependencies. Electron code seems to use AURA but assumes it's AURA X11 where it could be AURA / Wayland. I am not sure if there are any equivalents for the used X11 functions.

It would have been nice if some electron devs could evaluate that or bring some feedback / techincal considerations here :)

[NeoTheThird]

Any news on this?

[tonikitoo]

hi! I just wanted to share that we (from Igalia) have support for Wayland in both Chromium (the browser) and Content (the embedding layer) levels in https://github.com/Igalia/chromium/.

So depending on how one configures electron on top of a regular chromium/x11 build today, it might be really straightforward to try it out on top of chromium/wayland.

The biggest differences are that:

• chromium/wayland builds have "ozone" enabled.
• chromium/wayland runs on top of the the under development "UI service", in chromium-land.

please reach me out at \tonikitoo at igalia dot com\, if one wants to follow up on this.

[zichittella]

does anyone find a solution to run Electron without X11?

[luispabon]

@tonikitoo do you have any indication of when your work on Wayland will be integrated back upstream?

[tonikitoo]

@luispabon the work is being actively upstream. We estimate that about 85% is already in chromium's mainline.

/cc @msisov

[luispabon]

@tonikitoo excelente 👍

[zichittella]

hi @tonikitoo, any good news regarding electron with xwayland, wayland or weston?

[msisov]

we are not working on electron, but rather adding support for wayland in Chromium :)

crbug.com/578890

[danshick]

You'd also need a compositor that implements it, not sure if there's any that does yet.

I think sway does.

[1ace]

You'd also need a compositor that implements it, not sure if there's any that does yet.

I think sway does.

Indeed, wlroots implement text-input-unstable-v3 and sway makes use of that implementation.

[vially]

Version 12 of Electron with the initial Wayland support has just been released 🎉 .

[iMonZ]

Version 12 of Electron with the initial Wayland support has just been released tada .

Okay so electron is released, but can you tell me where you found that “Wayland” statement? I searched the whole electron changelog and cant find a word about Wayland!

[vially]

There is nothing in the release notes about Wayland. I'm not sure what the criteria is for something to be mentioned in the release notes, but the Wayland support seems to be there and can be tested by installing the latest version and running:

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

[juxuanu]

This is a Chromium feature. Check Chromium's changelog for the Wayland news.

This issue can be closed.

[iMonZ]

This is a Chromium feature. Check Chromium's changelog for the Wayland news.

This issue can be closed.

Has someone tested this feature?
Is it approved?
Until this happens why close the issue?

[juxuanu]

This is a Chromium feature. Check Chromium's changelog for the Wayland news.
This issue can be closed.

Has someone tested this feature?
Is it approved?
Until this happens why close the issue?

I've been using Electron on Wayland for months now. Many people I know have, too.
I don't understand what approval and from whom you expect.
You can check for yourself on anything based on any of the last two major Chromium versions with the flags provided above.

[iMonZ]

This is a Chromium feature. Check Chromium's changelog for the Wayland news.
This issue can be closed.

Has someone tested this feature?
Is it approved?
Until this happens why close the issue?

I've been using Electron on Wayland for months now. Many people I know have, too.
I don't understand what approval and from whom you expect.
You can check for yourself on anything based on any of the last two major Chromium versions with the flags provided above.

Okay well that parameter worked fine but my window doesn't have borders or a top bar and I cannot move or resize the window 🤔️

[Synthetica9]

[...]

Okay well that parameter worked fine but my window doesn't have borders or a top bar and I cannot move or resize the window thinking

That's probably a client-side decorations thing, see here for a starting point

[vially]

but my window doesn't have borders or a top bar and I cannot move or resize the window

That's a known issue which is specific to GNOME (or more accurately specific to compositors which don't support server-side decorations).

It has also been spun-out as a separate Electron feature request in #27522 (also related: #27016, #11907).

[jokeyrhyme]

Congratulations on v12 :) <3

Please close this issue and lock further comments, so individual topics around wayland polish can be raised separately

[ZanderBrown]

Being picky: It's not a bug with GNOME and it's not GNOME specific, however it's probably a Chrome issue

[RJVB]

Congratulations on v12 :) <3

Please close this issue and lock further comments, so individual topics around wayland polish can be raised separately

Before I do that: is it already possible to set up things in such a way that Electron-based applications use Wayland automatically when it's available (or the only option)? If not, are there plans to do this and thus remove the need to remember and add --enable-features=UseOzonePlatform --ozone-platform=wayland each time you launch such an app?

[msisov]

This automation is not in Chromium source tree yet, but it's on its way - https://chromium-review.googlesource.com/c/chromium/src/+/3188974

[sepehr]

If the electron app runs as a flatpak, there's need for a flatpak override that:

• exposes Wayland socket
• sets GDK_BACKEND environment variable to wayland

You can create this override with:

flatpak override --user --socket=wayland $VENDOR
GDK_BACKEND=wayland flatpak run $VENDOR --enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations

Where $VENDOR is the flatpak vendor, e.g. com.slack.Slack or org.signal.Signal. The override will be created under ~/.local/share/flatpak/overrides.

Another convenient option is to use Flatseal. On Arch, you can override all Electron apps flags globally.

---

P.S. been my first day back on a gnu/linux workstation battlefield.

[aaronliu0130]

Apparently Chromium now supports native Wayland. Is there an update on this?