Wayland: Screensharing is difficult to use #829
Labels
GNU/Linux
Issues affecting GNU/Linux
Comments
|
Can you get the crash backtrace, if you launch it from a terminal? |
|
I will try to do what you ask. I will have to re-install the 23.1.0 versions again, though. I'll do it as soon as I can, both with the deb and with the AppImage. As I wrote in my post, I had re-installed the 22.12.0 version, which does what it needs to do. |
|
@Alfagiovanni56 the only change from 2022.12.0 to 2023.1.0 is the update from Electron 21 to Electron 22 (with Chromium 106 -> 108 inside). In the past few versions Wayland support has gotten better in Electron, but as you mention it, it may have gone backwards this time with Electron 22. From a first look this could be related: electron/electron#36660 |
|
I have openend both the latest AppImage and the deb version from a terminal. Since I don't know how to save the terminal output into a file, I have made several sreenshots of the output, since after a while it didn't match one screen anynmore. For both the AppImage and the deb file there are 4 screens:
|
|
Sorry, closing the issue was a mistake. I wanted to close my post! |
|
I have the same behaviour on Fedora 37 + Wayland/Nvidia. I'm using the From the TRACE I can see some "Permission denied" on |
|
@goldyfruit goldyfruit I have tried all available versions, including flatpak. The deb and AppImage packages open and function normally and crash only when trying screen sharing. The Flatpak even refuses to start up. On clicking the Jitsi icon nothing happens! |
Exactly the same for me. |
|
The permission errors sound relevant. Please note the Flatpak version is a third-party build. We don't support that one ourselves. |
|
I am aware of the fact that Flatpak is third party. I just tried them all to compare their behaviour within a wayland session. Normally I use the deb version. |
|
I got this from my kernel log: Here is the generated Here is the generated |
|
I'm experiencing this issue on Arch Linux with Gnome 43.2 and Wayland. This is the output: |
|
This is now fixed by reverting back to electron 21. This is not a sustainable fix, as electron 21 is EOL around April this year, so we will need to find a way why this breaks in electron 22+ and how to fix it permanently. |
|
I'd say that is up to Electron to fix. We can't be beholden to an old Electron version because Wayland is broken. Long term, that is. |
|
Thx for taking care of this, even if - for the moment being - with a workaround. I hope it will give us (jitsi community, electron, ...) more time for permanent, future oriented solutions. I could be wrong and I am a relative outsider, but I have the impression that there could also be something in the relationship between Jitsi and Electron. I have other electron-based packages (e.g. Teams-for-Linux, which I use only if necessary to participate in meetings not organised by me) which allow screen sharing. Perhaps they are based on previous versions too. Anyhow, Electron should be (made) aware of this kind of problems with Wayland, in order to facilitate permanent solutions. |
|
Last reflection, following my previous mail. It could well be that the problem is not so much between jitsi and Electron or about Electron and Wayland, but more in particular between chrome-based browsers and Wayland. How else can we explain that in linux sessions with Wayland, Firefox allows screen sharing without any problem, but Brave and Google Chrome don't? That is one of the reasons why, as a user of Brave, at this moment I am so dependent on the Electron app and can't easily switch to the web version. |
|
When we say Electron bug we really mean a Chromium bug here :-) |
|
Exactly! |
|
I can confirm that this workaround (going back to Electron 21) allows sharing screen on Arch Linux. Let's hope screen sharing gets fixed in newer Electron versions before EOL. |
2 tasks
csett86
added a commit
that referenced
this issue
May 10, 2023
csett86
added a commit
that referenced
this issue
May 10, 2023
* chore(deps) update Electron to 24 * docs: document broken screensharing on wayland See #829 --------- Co-authored-by: Christoph Settgast <[email protected]>
|
As Electron 21 is EOL, we now have to upgrade. Unfortunately that means that screensharing is broken under wayland (segfaulting). Other electron apps are also affected, see electron/electron#37463 Only workaround is using X11 or a browser instead of the app under wayland. |
d3473r
pushed a commit
to d3473r/jitsi-meet-electron
that referenced
this issue
Sep 1, 2023
) Fix linux/wayland screenshare by electron downgrade to 21 Closes: jitsi#829
d3473r
pushed a commit
to d3473r/jitsi-meet-electron
that referenced
this issue
Sep 1, 2023
* chore(deps) update Electron to 24 * docs: document broken screensharing on wayland See jitsi#829 --------- Co-authored-by: Christoph Settgast <[email protected]>
d3473r
pushed a commit
to d3473r/jitsi-meet-electron
that referenced
this issue
Sep 1, 2023
Contains the fix for the hard crash on wayland when starting screenshare. Unfortunately it now hard-crashes when stopping screensharing. The hard crash on starting screensharing is fixed, but its still relatively unreliable to share the screen under wayland. Background is electron/electron#39043, and same as described there two Pipewire pickers open, and the user has to select and accept both, then be quick in the jitsi selector as well and then it works. If one Pipewire picker is cancelled by the user, the process hangs. If the user is too slow in the jitsi selector, the two Pipewire pickers pop up again. See: jitsi#829
|
Just wanted to let You know that some time ago I just build a version using older version of Electron and it seemed to work fine. |
|
Note that old electron versions get phased out and stop getting security fixes. |
|
It seems that the best option here is to focus on fixing the features, if a program doesn't work, I don't care about its security. |
|
I wholeheartedly disagree. |
Thank You for the comment - and other ones too. I do think it's not the best solution, but for the people who do need this feature and don't use the application, let's say, professionally or often, I think it may be useful - until the proper resolution got released. I, by the way, did it myself this way as I couldn't keep on using the older version of this application as every time I closed it, it got auto updated. I know it's a known "issue". |
csett86
added a commit
that referenced
this issue
Sep 4, 2023
Contains the fix for the pipewire selector. Its now a combined selector, same as Chrome/Firefox, and contains the fix for the hard crash on wayland when stopping screenshare. Unfortunately sharing the full screen still does not work under wayland, only sharing individual windows (tested with Ubuntu 22.04). Sharing a windows is still very cumbersome, as one needs to select the window in the pipewire selector, then quickly select it in the jitsi built-in selector as well and then it works. If one is too slow (>2 seconds) on the second selector, the pipewire selector comes up again. See: #829
Yes. That is precisely why I made the above comment, to point you to a solution that you don't consider viable. But I understand that it needs to be clarified a bit. Point 1, is that using an older version of electron does not reduce security as much as you think. Make no mistake older versions of electron are extremely dangerous in terms of CVEs and such, it's just that until #904 is completed, you're trading a working feature with 1% less security for a thing that has slightly more (1% in particular) security but doesn't have a working feature. Now to qualify the 1% figure. Software is generally written to improve. In actuality code often introduces bugs, so it's not easy to reason about whether SO: the best solution is to merge #904 and be done with it. AFAICT, the problem was upstream so a simple version bump can resolve it. If it does not, then consider other options. The second best solution is to rely on the older version of electron until #904 is merged and until screensharing is fixed on The third best option is to rely on the community to be patient. But with a service that has already done a lot to lose its audience I don't think it's a good option. I convinced my (now former) company to move all our meetings out of Zoom, and into Jitsi. After that, every single point that I made in favour of Jitsi, including the fact that at the time it was the only way to get screensharing on GNU Linux reliably, were proven to be false by bad development practice (not updating to 26.1 this long) and non-pragmatic approach to features and bugfixes (refusing to rollback a library after it was proven to break a function). What's more ironic, is that in all of those cases, a simple message that said, try the same link in the browser until we fix #829, would have done wonders, because most people that work in the company are not technical. The fact that Do with this information what you will. I suspect you will not take it as advice, but rather as a hostile gesture. But on the off-chance that you do take it as advice, this isn't a blame game. I'm maintaining FOSS too. We don't have the budget to move forward with semver incompatible upgrades. Often those break existing functionality and we find out about it on very short notice. There are pragmatic steps that could be taken in such situations and rolling back an already outdated version of a library dependency is always an option. |
|
@appetrosyan I share your sympathies with working software, but we can only do so much if electron breaks upstream. In this specific case we did the rollback to Electron 21 initially and then held off upgrading Electron as long as possible: #829 (comment) |
csett86
changed the title
|
The new version of jitsi-meet-electron v2023.9.0 is out now: Screensharing got a bit better, its no longer crashing, but sharing the full screen under wayland is still not possible, unfortunately. Sharing a window is still very cumbersome, as one needs to select the window in the pipewire selector, then quickly select it in the jitsi built-in selector as well and then it works. If one is too slow (>2 seconds) on the second selector, the pipewire selector comes up again. |
|
That UX problem can be fixed in a separate issue. |
csett86
changed the title
|
FYI: The new version of jitsi-meet-electron v2023.9.1 is out now: We are back to two overlapping Pipewire prompts under Wayland, as the electron 26 was crashing on Fedora and Arch Sharing a window is still very cumbersome, as one needs to select something in the screen and the window prompt, then quickly select it in the jitsi built-in selector as well and then it works. If one is too slow (>2 seconds) on the second selector, the pipewire selector comes up again. But if you are quick, you can successfully share your screen. |
|
Hi, do we know what exactly is crashing? Mattermost updated to Electron 26.2.1 and it a) works on fedora 38 & 39 and b) only shows a single pipewire dialog (afterwards one still has to confirm the selection in a mattermost specific source dialog, but that is to be expected for now). |
|
On the linked Electron issue you can see more details. Many other applications seem affected and last I checked it wasn't clear what the cause is, still. |
|
@saghul I think I clicked through most of them and they all seem to be merged. This comment ( #829 (comment) ) said that 26 probably fixes most of the issues and now #829 (comment) seems to suggest that there are again crashes on 26 -- but I cannot find the relevant issues for it. You said "many other applications seem affected" and yes I agree that many other applications were affected (among them mattermost), but it seems that some of those applications (like mattermost) no longer crash on 26.2.1. Hence I am asking for details on what is crashing here currently… |
|
This is the upstream issue, which is not solved yet: electron/electron#39775 |
csett86
added a commit
that referenced
this issue
Oct 1, 2023
Main change: backport of merged Pipewire picker under wayland. Now redundant pickers for screen and application windows does not popup, unfortunately full screen sharing is no longer possible with this. See: #829
csett86
added a commit
that referenced
this issue
Oct 1, 2023
Main change: backport of merged Pipewire picker under wayland. Now redundant pickers for screen and application windows does not popup, unfortunately full screen sharing is no longer possible with this. See: #829
|
Via web browser the screen can be shared but it asks 2 times to share the screen before allow sharing it, but from the app it enters in an infinite asking loop to share the screen. I'm in openSUSE TW with KDE and wayland. |
@saghul That upstream issue has been fixed! |
|
That won't solve the double dialogs IIRC. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This Issue tracker is only for reporting bugs and tracking code related issues.
Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed. General questions, installation help, and feature requests can also be posted to community.jitsi.org.
Description
I had installed the newest version of jitsi-meet-electron 23.1.0 ([jitsi-meet-amd64.deb) on my machine (Ubuntu 22.04). Within a wayland session - which is default on Ubuntu 22.04 - the app crashes whenever one tries screen sharing. I had a frozen image once, but most of the time the app simply closes down. I have also tried to install the latest AppImage, which causes exactly the same type of crash.
When opening an online session on Brave or Chrome, screen sharing is simply impossible within a Wayland session, with the single exception of other browser pages in Brave resp. Chrome. Finally even the Firefox (snap) crashes in a Wayland session when one tries to share a screen.
Unfortunately, this makes it almost impossible for me to use the latest versions of the electron app. Therefore I have decided to re-install the 22.12.0 version for the time being. I hope that it will be possible to reproduce the problem and to of course to resolved it as soon as possible.
My machine is an Ubuntu 22.04.1, Gnome 42.5 and Wayland.
Current behavior
App crashes on screen sharing: closes down unexpectedly.
Expected Behavior
Share one's screen going through the normal procedure / choices (whole screen or window etc...
Possible Solution
???
Steps to reproduce
Start session on ubuntu 22.04 / wayland and try screen sharing. Compare with an Xorg session
Environment details
The text was updated successfully, but these errors were encountered: