Element doesn't work well with native Wayland #728
Comments
|
Updating to Electron 14 will allow (hopefully) the desktop app to use KDE's file picker when uploading files with |
|
Electron 14 pulls in chrome 93 which causes problems with jitsi. We'll need to make sure these are fixed before updating. |
|
fedora 35 has a repo for element which unfortunately does not work (anymore) because element needs a newer version of electron. workaround (at the moment) is to pass --disable-seccomp-filter-sandbox as start parameter, see element-hq/element-web#19329 |
|
Where can I read more about these issues with Jitsi? Could an upgrade to Electron v15 be done directly? (that's based on Chromium 94) |
novocaine
changed the title
|
Changing this into a defect which describes the actual problem as we have a few people filing against this. I think there is a known workaround noted in #728 to get it to at least start, but I'm uncertain if that solves all problems so maybe S-major is best. Changing to O-Uncommon because I think Wayland users are a small % of our user base |
|
@jplatte - how confident are you that upgrading to Electron 14 will actually solve the Wayland issues? Are you just basing that off other Electron 14 apps seeming okay? I couldn't quickly find anything specific about Electron 14 that suggests its Wayland support is improved - I worry Element just has some specific issues that need be worked through that aren't linked to Electron version.. If you're game for testing it on your system, you could try flipping this line to 14 locally and taking the build for a spin.. |
Yes
Have you checked the corresponding Chromium changelogs?
Sure, will try tomorrow. |
I have not! Can you link to what you've noticed?
Awesome :) |
|
the problem i reported is not linked to wayland(!), this problem occurs on all fedora 35 versions, no matter which x window system is used. |
|
So I changed that line, built and ran with |
|
Oh, actually |
|
Starting from git w/o a config directory, or only at the old
Not going to open a separate issue because the issue template looks super complicated ._. Edit: Also Ctrl+Q w/ Electron 14 + Wayland (which then displays a nicer-looking gtk3 dialog) doesn't work. I can press "Close Element", but nothing happens. |
|
Alright so I managed to run it with native wayland & electron 14. The close confirmation prompt bug remains and the mouse cursor is tiny when on the window (same in regular Chromium, there's a reason using this still requires cmdline flags), but otherwise it seems usable. Notably, Jitsi works¹. ¹ I added a widget w/ the integration manager; the conference name was literally |
Thanks so much for getting this working and testing. Sounds promising, we will see what testing produces on other platforms. |
Okay - element-hq/element-web#19743 (comment) suggests that @jakobkmar at least can run Element under XOrg on Fedora 35, unless I have misunderstood something (quite possible). If you can't get it to run under XOrg on Fedora 35, then I think we should re-open your ticket as a distinct issue (and sorry for the runaround ;) |
You understood it correctly, for me it is only a Wayland issue, not a Fedora issue. |
|
not sure what happened but the latest version from taw (fedora repository for element) does not require --disable-seccomp anymore, so i guess that has been updated and my problem is solved |
@novocaine Has there been any progress? Just got a HiDPI notebook and Element is looking quite bad since it is drawn at low resolution and then upscaled. |
|
#299 upgrades to Electron 16 which will hopefully close this issue out. |
|
That wasn't intentional. What I wanted to actually comment is that all my Electron apps except VSCode (for some reason) have regressed on this, and are now segfaulting at start (albeit only if Relevant upstream bug might be electron/electron#31885. |
|
I tried with a dev build of element-desktop + element-web 1.9.8. It worked with my locally-installed electron from the arch linux repository while segfaulting with |
|
Update: Actually, the locally-installed one crashes too.. When it launches a |
|
if you're doing your own build .. you could try hacking in the electron crash reporter? e.g. like electron/electron#26509 (comment) (on our list to integrate this properly) |
|
As long as the stack traces are all |
|
are the stack traces totally blank, or do they tell you which executable/binary the frames are in (even if the function names are missing)? if the latter, you can still see which library is responsible for the crash |
|
|
I found a way to get stack traces without compiling electron myself:
This results in Still not complete, but at least better than nothing. |
|
Looks like this is indeed electron/electron#31885 (or electron/electron#32436 if that's not a duplicate). Either way I get the same stacktrace (on 17-beta.7 too), and the proposed fix from the first issue, electron/electron#29618, also doesn't work 🙁 I guess that PR is a good place to follow up on this. |
|
I found a workaround (instructions are arch-specific) for native-wayland Element on sway!
|
|
for me simply works this:
|
|
I tested it on my machine and it seems like element-desktop crashes with only when trying to run it with latest electron22 on Arch Linux. I installed |
Changelog: https://www.electronjs.org/docs/breaking-changes#planned-breaking-api-changes-140
I've just tried running Element in native Wayland mode (
--enable-features=UseOzonePlatform --ozone-platform=wayland) and it seems that currently breaks Element entirely in smoe circumstances (had the window be fully transparent at startup once, and in general it goes all white when trying to join a Jitsi conference). All my apps using Electron 14 as well as Chromium seem to run fine with these flags so I hope once Element upgrades it will work too :)Being able to run Element natively under Wayland would have many advantages, most notably proper HiDPI support in wayland-based desktop environments.
The text was updated successfully, but these errors were encountered: