Issue 1:
Electron version: 1.7.x

Operating system: Windows 10

Expected behavior

You should be able to share any screen connected on the computer, see the content of the screen you selected locally, as well as the other participants.

Actual behavior

Once you select the screen you want to share on a multi-screen computer running Windows 10, you immediately get a black screen as the local stream when you select some of the screens. The other participants also get a black screen as the remote stream.

How to reproduce

On a Windows 10 computer or VM, with multiple screens connected, start sharing your screen with any Electron-based app. I reproduced the issue with the Symphony client, but also with this one which is fully open source:

$ git clone https://github.com/jitsi/jitsi-meet-electron/

$ npm install

$ npm start

Once you select the screen you want to share, you immediately get a black screen as the local stream. The other participants also get a black screen as the remote stream. The issue appears to affect the screens randomly, sometimes the impacted screens are the screens number 2, 4, 6, sometimes after a reboot, 4, 5, 6, etc...

Root cause analysis

At the system level, the way Windows 10 enumerates the screens is slightly different when a virtual video driver is involved.

On Electron, the picker window is managed by the DesktopCapturerSource object: https://github.com/electron/electron/blob/master/docs/api/structures/desktop-capturer-source.md and the mapping relies on a naming rule https://github.com/electron/electron/blob/master/atom/browser/api/atom_api_desktop_capturer.cc that fails when a non-conventional video driver is involved.

At Symphony, we experienced the exact same issue with CEF/Paragon. This is how we fixed the problem of the screen IDs enumeration: symphonyoss/SFE-DesktopClient-pgx@85f0d71#diff-7e750064e4ad7245e99d95316f830119

This fix also addresses a similar issue we had with one monitor, but with Citrix XenDesktop installed (https://www.citrix.com/products/xenapp-xendesktop/), which also alters how Windows enumerates the screens.

FYI, this is how the WebRTC native code that does enumeration: https://webrtc.googlesource.com/src/+/master/modules/desktop_capture/win/screen_capture_utils.cc

Issue 2:
Electron version: 1.7.3 - not sure when this was introduced, works fine in latest production build based on 1.4.15

Operating system: Windows

Expected behavior

I have three screens connected to my computer. desktopCapturer.getSources({types: ['screen']}) correctly identifies three sources.

I want to share my first screen and set chromeMediaSourceId to the matching id screen:0:0 in the constraints when requesting the MediaStream using navigator.mediaDevices.getUserMedia(). I should get a MediaStream containing a video track with the content of the first screen.

Actual behavior

The stream returned will show the content of the second screen. If I ask for the second screen, I get the third screen. If I ask for the third screen, I get a black screen.

How to reproduce

https://github.com/wireapp/wire-desktop

git clone https://github.com/wireapp/wire-desktop.git
npm install
npm run prod

Log in or create a Wire account. Feel free to connect to me (@gregor)

Start audio or video call

Click on share your screen

Select screen to be shared