Screen Sharing broken 4.7.0 about webcord

[ionspin]

My experience, without logs unfortunately, Webcord 4.7.0 on Arch Linux with i3 (nvidia proprietary drivers):

• Screen/window picker shows up
• Clicking on any window or screen closes the picker and the sharing doesn't start.
  Also confirmed on colleagues setup with Webcord 4.7.0 on Arch Linux with Gnome (amd drivers), same behavior.

Downgrading to 4.6.1 solved the issue on both machines.

[PeterPorker3]

I am experiencing the exact same behavior as @ionspin, rolling back to 4.6.1 fixes the issue. I'm running Q4OS (Debain Linux with KDE Plasma x11), and I'm using the flatpak releases. full system information here:

Operating System: Debian GNU/Linux 12
KDE Plasma Version: 5.27.5
KDE Frameworks Version: 5.103.0
Qt Version: 5.15.8
Kernel Version: 6.1.0-17-amd64 (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 PRO 4750U with Radeon Graphics
Memory: 44.8 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: LENOVO
Product Name: 20UD000CUS
System Version: ThinkPad T14 Gen 1

I'm not sure what logs to check, but I would like to help get this issue fixed, Webcord has been very stable for me otherwise. If anyone knows what other information would be useful, I would be happy to share.

[Smexey]

I was able to reproduce this by pressing cancel on the GNOME popup which triggers the promise exception. Afterwards screen share button doesn't do anything and gets fixed with ctrl+r. Screen sharing otherwise works great.

I'm on 4.8.0 rpm and electron 29.0.0
Fedora 39, gnome

❯ webcord --trace-warnings
[UPDATE] Application is up-to-date!
[WebSocket] Listening at port 6463.
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
'loop->recurse > 0' failed at ../src/pipewire/thread-loop.c:426 pw_thread_loop_wait()
[117293:0306/123101.388987:ERROR:screencast_portal.cc(367)] Failed to start the screen cast session.
[117293:0306/123101.389041:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 2
(node:117293) UnhandledPromiseRejectionWarning: Failed to get sources.
    at emitUnhandledRejectionWarning (node:internal/process/promises:203:15)
    at processPromiseRejections (node:internal/process/promises:297:13)
    at processTicksAndRejections (node:internal/process/task_queues:96:32)
(node:117293) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)

[Qurcaivel]

I was able to reproduce this by pressing cancel on the GNOME popup which triggers the promise exception. Afterwards screen share button doesn't do anything and gets fixed with ctrl+r. Screen sharing otherwise works great.

As for me, in a Plasma Wayland session under XWayland, this works well, but leads to various issues when using "ozone".

For example, starting screenshare from KDE Screen Share portal works well, but If I close Portal window without starting screensharing it will produce:

[24517:0308/204038.586720:ERROR:screencast_portal.cc(367)] Failed to start the screen cast session.
[24517:0308/204038.586743:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 2
(node:24517) UnhandledPromiseRejectionWarning: Failed to get sources.
(Use `electron --trace-warnings ...` to show where the warning was created)
(node:24517) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)

Also, successully started screensharing produces:

'loop->recurse > 0' failed at ../pipewire/src/pipewire/thread-loop.c:426 pw_thread_loop_wait()

[ionspin]

As of 4.8.0 screen sharing is working properly for me. Thanks for your work on webcord!

[SpacingBat3]

Please explain further what's wrong with it, so far it worked for me just fine on Linux and with Electron 29 I've even had a success screen sharing with audio enabled.

[SpacingBat3]

(FYI, Electron 29 is still in beta, which is main reason why I didn't make an update to it.)

[PedrelliMath]

I'm using AppImage, I just changed my webcord.desktop Exec= to the new version, and when using screen sharing a notification appears in the top bar and then disappears. Linux Ubuntu 22.0.4

[SpacingBat3]

I guess it would help if you could show how it works (screen capture or screenshots are welcome), share some logs (whatever could show if there's anything going on when clicking on the button, both from DevTools and the STDOUT/STDERR) from the app or at least just tell if the bug happens on your side with Wayland/XWayland or X11…

I just need more info. I can't help if I can't reproduce it, and I'm Linux user as well (except I'm still on X11, my main DE doesn't support Wayland yet).

[floriansagerer]

I am on Arch Linux, Hyprland; starting in a terminal it outputs

'loop->recurse > 0' failed at ../pipewire/src/pipewire/thread-loop.c:426 pw_thread_loop_wait()

when sharing using xdg-desktop-portal-hyprland

and

[31480:0130/213630.914844:ERROR:screencast_portal.cc(325)] Failed to select sources for the screen cast session.
[31480:0130/213630.914864:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 3
(node:31480) UnhandledPromiseRejectionWarning: Failed to get sources.
(Use `electron --trace-warnings ...` to show where the warning was created)
(node:31480) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)

when sharing using xdg-desktop-portal-wlr.

In the webcord gui itself nothing happens.

[SpacingBat3]

Looks like this is a problem then on your side or (maybe) with the PipeWire screen sharing provider (at least from the logs given by @floriansagerer and my tests) – I was able to trigger the PipeWire screen sharing once I've set up GNOME correctly – but given I'm on (still kinda experimental, yet promising) nouveau + GSP.bin, GNOME shell literally crashes for me once I start the screen share and throws me back to the display manager.

[SpacingBat3]

(I'm on Arch as well, without testing packages installed, so the version of PipeWire or anything else is likely the same.)

[floriansagerer]

Same setup works in OBS and Vencord.

[SpacingBat3]

Then again, why I was able to trigger the GNOME screen share menu and you claim nothing happens? It feels rather odd it works for me in GNOME just fine yet you claim on Hyprland/Wlroots portals implementation it just crashes? Also Chromium somehow points this (as far as I understand the logs correctly) as an internal error returned by screen share picker...

[SpacingBat3]

Then again, why I was able to trigger the GNOME screen share menu and you claim nothing happens?

That's the main reason I think it might be somehow a problem specific to the given picker implementation. However, if you could reproduce the same error in GNOME as well, it feels like this problem is somehow related to your current workflow, since again, picker seems to be triggered just fine on my side. I might check again if Chromium behaves differently.

Also, about the new API I've moved to, it seems Vencord already uses it as well. So it could be also somehow related to the Electron version, I don't think the implementation is any different from Vencord in case of triggering the PipeWire screen share picker.

[SpacingBat3]

(...) and I'm using the flatpak releases.

I should say, bugs reported under flatpaks won't be resolved by me (flatpaks are not maintained by me, and are not maintained by anyone right now), so any comment regarding reproducing it with flatpaks will likely be ignored. The same is with snaps or any other packaging method outside of official builds, especially for those running under a sandbox.