Native wayland support

[nidico]

Element-desktop on Linux currently doesn't natively run under Wayland but requires Xwayland.

Being able to run element-desktop in native wayland would be favorable (no Xwayland requirement, less performance overhead, better HiDPI support, ...).

The good news is that this can already be achieved with a nightly version of electron (i.e. version 12), as this supports native wayland for a couple of days now! See electron/electron#10915 for the state of wayland support in electron.

In order to try it out, follow the instructions for local development in the element-desktop README and just do yarn add electron-nightly instead of yarn add electron and run with yarn start --enable-features=UseOzonePlatform --ozone-platform=wayland.

According to electron/electron#10915 decorations might be missing in Gnome/mutter, as mutter requires client-side decorations and electron doesn't do them yet. I don't know whether this is an issue, as I'm not using Gnome.

In sway everything works fine so far on a quick glance!

Electron 12 might be out in February (rough guess from looking at the release schedule), so this issue can hopefully be resolved in the foreseeable future, yay!

[532910]

Element looks ugly on HiDPI sway. Electron supports Wayland now, latest jitsi works fine for example. Please rise the priority.

[WhyNotHugo]

It seems that electron 11.4.1 is used now. Upgrading to electron 12 would be the first step here.

This'd close lots of rendering bugs on Linux desktop, plus improve security (compared to XWayland, at least).

[SimonBrandner]

Upgrading to electron 12 would be the first step here.

That is something that is planned

[Tggltn]

Upgrading to electron 12 would be the first step here.

Electron12 and Element-Desktop build with it are in community Repo of Arch now. So Arch Users can use it.
https://archlinux.org/packages/community/x86_64/element-desktop/
Works OK so far have only from time to time some "Renderer process crashed"(the window goes full white) if i use the Wayland back end. Will try to debug.

Renderer Crashes are so far only if a video does get displayed. (on sway and kde. Gnome has not that problem) Text channel work fine.

Element/1.7.23 Chrome/89.0.4389.90 Electron/12.0.2
running with
element-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland

(tested with xeyes if it uses Wayland)

[nidico]

With #178, electron has been upgraded to 12.0.2, yay! This has now been released in the stable release 1.7.25.

Running element-desktop with wayland seems to work fine with:

element-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland

I'll close the issue here and suggest to create separate issues for any findings.

(So far, I have noticed one minor issue: Resizing with ctrl-+ / ctrl-- doesn't seem to work on wayland.)

[532910]

Awesome! I confirm that it works.

[whoizit]

not work for me

I have:

• Void Linux updated
• sway wm
• electron-12.0.2
• element-1.7.25

i do:
element-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland
but xeyes reacting to a mouse over element

~ $ cat /bin/element-desktop 
#!/bin/sh
exec electron12 /usr/lib/element-desktop/resources/app.asar "$@"

[nidico]

In my case it is working fine on Debian testing with sway with element-desktop from the riot.im repo. I'm testing with xwininfo though, as xeyes doesn't work for me.

[532910]

I tested on sway/debian sid with xwayland disable option.

[whoizit]

strange, after reboot it works

[pimeys]

Works and is quite stable on NixOS/Sway with version 1.7.25. What I noticed though is a bit janky scrolling. It's not as smooth as Firefox or Slack on Wayland, so might be a bug in Element?

[beedaddy]

On Gnome (40.2), starting element with /usr/bin/element-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland, I have no titlebar and thus can't move the window. Am I doing something wrong?

Arch Linux
Element Desktop version 1.7.29
Electron version 12.0.13

[WhyNotHugo]

@beedaddy Gnome does not support rendering the decorations itself like other compositors.

This is a well known issue and the Gnome team has made it clear that they will not address it. Each individual application has to implements its own decorations to work properly in Gnome. Work on this is being tracked in the Electron issue tracker.

Regarding moving windows, can't you hold Super and click-drag to move windows around?

[beedaddy]

@WhyNotHugo Thanks for the explanation!

Regarding the Super-key, yes, that is possible. But after closing to tray and re-opening, the window again is at the top-left corner.
But anyway, I can stick to XWayland for now, although then there's an issue with opening links with firefox. But that's a different story. :)

[WhyNotHugo]

But after closing to tray and re-opening, the window again is at the top-left corner.

Sounds like a separate issue, might be worth opening a separate issue.

[ItsEthra]

Hey, I am experiencing some issues with element on Arch Linux wayland with Hyprland.
If I run just element-desktop it uses xwayland but if I run element-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland It just crashes.

/home/user/.config/Element exists: yes
/home/user/.config/Riot exists: no

(electron:20711): Gtk-WARNING **: 19:46:50.227: Theme parsing error: gtk.css:1:88: Failed to import: The resource at “/com/plata-theme/gtk-3.20-dark-compact/gtk-contained-dark.css” does not exist
No update_base_url is defined: auto update is disabled
[20755:0407/194650.454131:ERROR:gpu_init.cc(523)] Passthrough is not supported, GL is egl, ANGLE is
Fetching translation json for locale: en_EN
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change
Resetting the UI components after locale change
[20711:0407/194650.487274:ERROR:browser_main_loop.cc(271)] Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed
fish: Job 1, 'element-desktop --enable-featur…' terminated by signal SIGSEGV (Address boundary error)

[Ashark]

For me it was fine at first try element-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland. Then I tried --ozone-platform-hint=auto as said in ArchWiki. And then it started crashing even with those options that worked before. [Seems it is not so recent electron version embedded, but I cannot find it out from about app, it only shows Element: 1.11.35 and Olm: 3.2.14].
To fix that, I completely removed ~/.config/Element and tried again element-desktop --enable-features=UseOzonePlatform --ozone-platform=wayland. It now did not crash, but showed a message saying it is configured incorrectly. Restart again (still with those options) and now it works.