Skip to main content
Fedor Indutny's Blog

Third Time Is the Charm

With the release of macOS Sequoia many developers must have started discovering new exciting changes in otherwise settled and stable APIs.

One good example is Electron's desktopCapturer that lets apps list windows and screens available for screensharing and then stream their contents during a video call. With the Sequoia release, however, using desktopCapturer directly presents an extra window to popup.

Enter Pac-Man #

Thankfully, Electron team was anticipating this API transition and has prepared a change that lets macOS developers leverage the new APIs and avoid the popup. After migrating the source code over, an unexpected oddity has appeared in the testing. When sharing the screen for the first and the second time screensharing the user would see the expected video:

Electron window with screensharing working correctly

However, when attempting to share the third time, a happy green Pac-Man would appear instead:

Electron window with screensharing with a Pac-Man

Having no such test screen in the app's source code, the suspicion has landed at this being either an Electron or Chromium issue.

The Process #

Just as with the most bugs, the fix consisted of three main steps:

Reproduction #

For Electron specifically, reproducing a bug in isolation is best done by running code in Electron Fiddle. Thankfully Electron's maintainers already had a gist prepared so the only work that had to be done was clicking the "Start" button three times.

Isolation #

Isolation requires modifications outside of the test code and thus a full Electron checkout. The best way to have it locally is to use official build tools. Roughly the following steps are needed:

npm i -g @electron/build-tools
e init --root=~/electron
e sync
e build

and then (after a few hours) ~/electron will contain (among other things):

Given the original patch, the first thing to check was whether the execution gets into patched ScreenCaptureKitDeviceMac::OnStart with the use_native_picker boolean set to true.

After adding a few C's "console.log" equivalents:

fprintf(stderr, "we are here!\n");

and rebuilding with e build, it became apparent that the third "Start" click doesn't get there at all.

Back-tracking from ScreenCaptureKitDeviceMac::OnStart to farther callees, it became clear that the issue is that Electron generates fake video source ids that clash with Chromium's fake source id for the test green screen which has a DesktopMediaID::kFakeId = -3.

The first "Start" click used window:-1:0 as an id, the second - window:-2:0, but when the id got to window:-3:0 the check:

desktop_id.id == DesktopMediaID::kFakeId

substituted the media stream with the test green screen.

Fix #

Now that the cause is known, the best solution appears to be to introduce an another fake desktop id and set it to -4. This id would now be kept fixed, and the second integer representing window id would be decremented for uniqueness instead. After much waiting for builds and testing, the final fix is just 69 lines long, and hopefully would prevent the clash of fake entities for good.

One never knows where an investigation might bring them, but thankfully this was a short fun trip. Thank you for letting me take you along on it. Until next time!