[Feature Request]: Expose setDisplayMediaRequestHandler disable_local_echo flag to enable audio output during recording

[theogravity]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

• We want to record the electron browser window for both audio and video.
• The BrowserWindow instance loads an external URL, which calls window.navigator.mediaDevices.getDisplayMedia() at some point.
• We've attached a handler to setDisplayMediaRequestHandler() in our preload, which returns the following: callback({ video: source, audio: mainBrowser.webContents.mainFrame });
  • The video source is obtained through desktopCapturer, but I don't think that has anything to do with this bug.
• When we assemble the stream to the MediaRecorder and perform recording, the browser window loses audio output when the recording starts, and resumes output when the recording stops.
• The recording itself properly records video and any audio made from the window during that time.

After a lot of investigation, I noticed a flag here in the PR that implements setDisplayMediaRequestHandler() (#30702):

shell/browser/electron_browser_context.cc

    } else if (result_dict.Get("audio", &rfh)) {
      devices.audio_device = blink::MediaStreamDevice(
          request.audio_type,
          content::WebContentsMediaCaptureId(rfh->GetProcess()->GetID(),
                                             rfh->GetRoutingID(),
                                             /* disable_local_echo= */ true)

And thought disable_local_echo might control audio loopback behavior.

I compiled a custom version of electron with that flag set to false and repeated the above steps, which correctly allowed audio to come through the speakers while recording was happening. The recording itself retained video and audio.

I am on an M2 Mac running Ventura 13.2.1.

(I have zero C++ experience and just used intuition to find this while looking at the PR for setDisplayMediaRequestHandler and followed the electron build guides to test my hypothesis.)

Proposed Solution

May I ask that an option be exposed for setDisplayMediaRequestHandler that controls the value of that particular flag? Or, have the option be part of the callback for the handler.

Alternatives Considered

Have not discovered any alternatives. Literature around setDisplayMediaRequestHandler is limited as it's a recently-released feature.

Additional Information

This bug ticket describes the behavior we experienced, although the context is a bit different (It references getUserMedia and chrome.tabCapture.

https://bugs.chromium.org/p/chromium/issues/detail?id=1403733