Improve Linux Wayland screen share dialog

Steps to reproduce

1. Screen share on Linux Wayland.
2. If you’re on 1.8.1 or earlier, ensure you’re passing --enable-features=WebRTCPipeWireCapturer at runtime (this is fixed in develop).

What happened?

The dialog is confusing and hard to understand.The dialog attempts to show a preview of your window(s) but there isn’t any.

To actually screen share you need to click the “Entire Screen” picture placeholder, and then click share. Both these steps add nothing useful to the experience when on Linux Wayland. The same is true if you try to share the “Application window” instead.

This issue is mainly because Wayland’s method for screen sharing is very different from how X11 does it. Applications cannot assume they have access to view the screen, they must specifically request it from the host system. Element needs to be aware of that difference and not show a redundant dialog.

This issue similarly affects another Electron app, Jitsi Meet.

What did you expect?

So the whole dialog “Share Content” is probably best skipped for Wayland, there’s no need to have 2 share buttons. When users click share they should be sent right to the PipeWire/Portal dialog.

So to recap: Current steps:

1. Click circular share button in video meeting box.
2. Click image with no actual picture.
3. Click rectangular share button.
4. Let host use PipeWire/Portal dialog to actually share.

Proposed steps for Linux Wayland users:

1. Click circular share button in video meeting box.
2. Let host use PipeWire/Portal dialog to actually share.

Operating system

Linux

Application version

Element version: 1.8.1 Olm version: 3.2.3

How did you install the app?

Flatpak, identically affects DEB

Have you submitted a rageshake?

No

[grulja]

@grulja sorry for the direct ping, but what do you know about app-created dialogs with PipeWire in Electron?

There is a seemingly universal issue for Electron sharing with PipeWire, where Electron apps continue trying to use the “X11 way” of screen sharing, meaning they’re under the assumption they should be able to see open windows and displays. The user is faced with a now redundant app-created dialog that adds confusion and extra clicks.

This is basically same problem we have with Chromium. Everytime a user wants to share a screen he has to go through the dialog presented by Chromium and there is no way to skip it even though it is redundant as they want to keep same UI/UX experience across all platforms. With Chromium you even get the portal dialog twice as one is used for preview in the Chromium dialog and the second one is for the actual content on the web page itself.

See the screenshot above and here: jitsi/jitsi-meet-electron#608.

In my mind, when a user clicks the share button in an app like Element, they should be taken right to the PipeWire/XDG Desktop Portal dialog.

Would it make sense for Electron itself to be patched so apps are prevented from creating their own dialog when under a Wayland session?

Yes, that would be the best solution, however, I have no idea how this all is implemented in Electron and if it’s something easy to do and if it’s something upstream would agree with. I tried to propose same change for Chromium and that change was rejected.

[SimonBrandner]

Would it make sense for Electron itself to be patched so apps are prevented from creating their own dialog when under a Wayland session?

As far as I can tell there isn’t much Electron can do besides the helper function because the way things work at the moment is that there is a method to get the sources and a method to request a media stream from one of them. I can’t really see what Electron could do differently here 🤷‍♂️