electron: [Bug]: DesktopCapturer doesn't work in Ubuntu 22.04.2 LTS

I looked into the PipeWire changes and it appears that regression is a result of major changes in how PipeWire capturer works.

Earlier, when an instance of NativeDesktopMediaList was created, it used to start all capturers. This would cause an XDG Desktop Portal permission dialog to pop up for PipeWire capturer. If permission is granted, the application could capture screen/window to show thumbnails. Once a selection was made and the desktop capture was to begin, another XDG Desktop Portal permission dialog would show up when the capture is restarted. This was the cause of #30652.

To address the double popup issue, Chromium now does not start the capturer during the instantiation of NativeDesktopMediaList if it’s “delegated”. Right now, PipeWire is the only delegated capturer. In addition to this, if you try to fetch the source list from PipeWire capturer before a selection is made on the XDG Desktop Portal permission dialog, you’ll get a placeholder source ID. These are the two reasons for the crash—the capturer is not started when NativeDesktopMediaList::Update is called and the capturer tries to capture thumbnails for a non-existent source ID.

The expected flow for delegated capturers is to call NativeDesktopMediaList::StartUpdating with an implementation of DesktopMediaListObserver. The desktopCapturer.getSources implementation should block until it receives OnDelegatedSourceListSelection or OnDelegatedSourceListDismissed. If desktopCapturer.getSources is called for both screens and windows, this should happen serially so that the two permission dialogs don’t show up on top of one another. The desktopCapturer.getSources implementation should return the source IDs received from OnSourceAdded/OnSourceRemoved/OnSourceMoved.

A quick and dirty way to fix the crash might be to patch DesktopMediaListBase::Update in Chromium to start the capturer and set thumbnail size to 0 if the capturer is delegated. This will take desktopCapturer.getSources back to the behavior before version 22. However, it will continue to return placeholder IDs.

I’ll try to take a stab at the proper fix next weekend. My C++ is very rusty, so if someone else wants to take over, feel free to do so.

Thanks! Symbolicated crash here: wayland_crash.txt

Looks like this is crashing within BaseCapturerPipeWire::CaptureFrame(). I put in an input check when creating the capturer to make sure we wouldn’t hard crash, but it looks like the capturer has been successfully created here. So the capturer is correctly finding PipeWire, but then failing further down the line 🤔 Will keep digging into this and see what’s going on.

I tried bisecting the crash using the gist shared by tghpereira on Fedora 38 Workstation. I arrived at a different results depending on the CLI flags. I could not reproduce any crash while running on X11.

While running on Wayland with --ozone-platform-hint=wayland and --enable-features=WebRTCPipeWireCapturer,WaylandWindowDecorations, the bisect was v22.0.0-nightly.20220908…v22.0.0-nightly.20220909. The diff includes a Chromium version roll. There are lots of PipeWire-related changes in the Chromium diff, but the ones that seemed relevant to me are:

1. 3846595: Auto-select PipeWire target once selection is made | https://chromium-review.googlesource.com/c/chromium/src/+/3846595
2. 273541: Allow splitting PipeWire picker into Screen and Window options | https://webrtc-review.googlesource.com/c/src/+/273541
3. 3864873: Stop erasing Window picker option when using PipeWire | https://chromium-review.googlesource.com/c/chromium/src/+/3864873
4. 3846372: Show/Hide PipeWire picker based on Chrome Picker state | https://chromium-review.googlesource.com/c/chromium/src/+/3846372

Perhaps some change here caused the regression in electron. I can reproduce the same bisect using --ozone-platform-hint=x11 and --enable-features=WebRTCPipeWireCapturer while running on Wayland. The cause of the crash in this scenario is always electron!webrtc::BaseCapturerPipeWire::CaptureFrame().

When I tested with --ozone-platform-hint=wayland and --enable-features=WaylandWindowDecorations, the bisect was v23.0.0-nightly.20221017…v23.0.0-nightly.20221018. However in the good version, the windows that were listed were XWayland windows of the electron process or its parent. This indicates that the X11 capturer was being used here. When I tried to reproduce this on 26.0.0-alpha.1, the cause of the crash changed to BaseCapturerPipeWire::CaptureFrame(). This makes sense, as PipeWire is now enabled by default in Chromium.

When I tested with --ozone-platform-hint=x11 or no flags at all, I arrived at the same bisect as @VerteDinde, that is v23.0.0-nightly.20221117…v23.0.0-nightly.20221118. Similar to the previous scenario, the windows listed by the good version were XWayland windows of the electron process or its parent, indicating the usage of X11 capturer. The cause of the crashes changes to PipeWire with 26.0.0-alpha.1 in this scenario as well, due to the same reason as before.

Summarizing, the PipeWire capturer broke between v22.0.0-nightly.20220908 and v22.0.0-nightly.20220909, likely due to a regression from one of the four mentioned CLs. The fallback to X11 capturer broke in different ways in subsequent nightlies, but these should not matter for new electron versions as PipeWire is now enabled by default. The X11 capturer also has significant limitations on what it can do in Wayland.

@tghpereira Last release that appears to work is 21.4.4 but release has 3 moderate severity vulnerabilities.