Bug 475496 - Attempting to screenshare via Discord causes the screenshare permission request menu to continuously open
Summary: Attempting to screenshare via Discord causes the screenshare permission reque...
Status: RESOLVED WORKSFORME
Alias: None
Product: XWaylandVideoBridge
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-10-12 04:01 UTC by Russ
Modified: 2023-11-11 03:45 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Russ 2023-10-12 04:01:44 UTC
SUMMARY

I am attempting to use XWaylandVideoBridge to allow Discord's screensharing to work while running under Wayland. With XWaylandVideoBridge active and attempting to start a screen share session from Discord, the "Screen Sharing - Portal" permission window comes up and asks me which screen/window to share. Upon selecting one and confirming, the window re-opens a couple of seconds later, and continues to do so unless I either move the window out of the way and confirm / use the start option within Discord, or close the screen sharing menu in Discord all together. 

When moving the portal window out of the way and selecting the output that XWaylandVideoBridge creates (and I can see the selected window/screen within it), Discord doesn't actually appear to receive anything (the preview window gets stuck at Discord's "loading" indicator). 


STEPS TO REPRODUCE
1. Install XWaylandVideoBridge and launch it
2. Connect to a voice channel within Discord or join a call
3. Attempt to start a screen share session

OBSERVED RESULT
The Screen Share Portal window continuously re-opens, and the screen/application doesn't seem to make it to Discord.

EXPECTED RESULT
A screen sharing session should properly activate

SOFTWARE/OS VERSIONS
Linux: EndeavourOS/Arch Linux
(available in About System)
KDE Plasma Version: 5.27.8
KDE Frameworks Version: 5.110.0
Qt Version: 5.15.11

ADDITIONAL INFORMATION
In Discord's logs, I can see the following:

```
[3722:1011/233507.362206:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 2
Error occurred in handler for 'DISCORD_DESKTOP_CAPTURER_GET_SOURCES': Failed to get sources.
[3722:1011/233514.310047:ERROR:screencast_portal.cc(367)] Failed to start the screen cast session.
[3722:1011/233514.310059:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 2
Error occurred in handler for 'DISCORD_DESKTOP_CAPTURER_GET_SOURCES': Failed to get sources.
Error occurred in handler for 'DISCORD_DESKTOP_CAPTURER_GET_SOURCES': Failed to get sources.
Error occurred in handler for 'DISCORD_DESKTOP_CAPTURER_GET_SOURCES': Failed to get sources.
```
Comment 1 David Edmundson 2023-10-12 07:11:09 UTC
>[3722:1011/233507.362206:ERROR:base_capturer_pipewire.cc(81)] ScreenCastPortal failed: 2

That's in discord's logs? That's very surprising, it implies it's doing pipewire stuff directly.
Can I have versions of discord + xwaylandvideobridge please
Comment 2 Russ 2023-10-12 20:22:35 UTC
Hello David,

Thanks for getting back to me quickly! Your comment had given me an idea to double check which version of Discord had been installed, and it looks like when I went to install Discord through Arch's package manager I inadvertently ended up selecting a special version that bundled a newer Electron version than Discord originally comes with, as the two selections were right next to each other.

After downloading the standard Discord tar from their site and running that, this behavior stopped - so I'm guessing the newer Electron version is what is causing Discord to attempt to use Pipewire (but still doesn't do so properly of course).

So this doesn't look to be a problem with XWaylandVideoBridge, just a silly user error on my part :)

I'm still new to KDE's bug tracker, so while I can see that I can change this bug report's status, I'm not sure which status to change it to. I take it that "RESOLVED NOTABUG" would be the one to use here? My apologies about the trouble!
Comment 3 Bug Janitor Service 2023-10-27 03:45:44 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Bug Janitor Service 2023-11-11 03:45:53 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!