Issue metadata
Sign in to add a comment
|
chrome.desktopCapture API mishandles multi-monitor setups on Linux
Reported by
jamesgal...@gmail.com,
Aug 15
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.84 Safari/537.36 Steps to reproduce the problem: 1. Attach and configure multiple monitors on a Linux desktop 2. Generate media stream with chrome.desktopCapture.chooseDesktopMedia(...) What is the expected behavior? The client should be able to choose one of the screens, windows, etc. and obtain the stream of *just* the specified content. What went wrong? Regardless of the user's choice of what to capture (in my testing even choosing a single window to capture is ignored), all monitors are streamed simultaneously as one larger screen. In the attached screenshot, the smaller section on the left (2, outlined in red) is a secondary monitor; the section on the right )1, outlined in blue) is the main monitor. This screenshot was taken while screen sharing on Discord, which is one of the applications affected by this bug. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 68.0.3440.84 Channel: stable OS Version: Debian 9.5 (Stretch) Flash Version: Shockwave Flash 30.0 r0 This issue encompasses a multitude of other issues that arise from this bug, given that the chrome.desktopCapture API is widely used. The bug seems to have persisted for almost almost 4 years now, without any action to fix it. The bug was previously discussed in https://bugs.chromium.org/p/chromium/issues/detail?id=660032 which was marked as a feature request. It discusses the bug in more depth, and includes some testing of affected applications. Chrome on Windows and OSX properly handles multi-monitor setups. There is no reason to believe support for this feature on Linux is impossible; see https://bugs.chromium.org/p/chromium/issues/detail?id=660032#c11: > ...this is a bug, not a feature; feature-parity is missing in this regard -- X11 proto/spec supports this... Further discussion/references, organized by where the bug manifested (listed roughly in order of usefulness): --- Google Hangouts https://bugs.chromium.org/p/chromium/issues/detail?id=660032 [Linked above] https://bugs.chromium.org/p/chromium/issues/detail?id=437507 https://unix.stackexchange.com/questions/152435/sharing-your-desktop-with-google-hangouts-dual-monitor-and-gnome-shell https://productforums.google.com/forum/#!msg/hangouts/JKc_v0lMTTg/gk7Rd5cZAgAJ Discord https://feedback.discordapp.com/forums/326712-discord-dream-land/suggestions/19416319-linux-multihead-screen-sharing-caveats-on-electron https://www.reddit.com/r/discordapp/comments/8540z0/how_discord_handles_duel_screen_linux/ Jitsi-Meet https://github.com/jitsi/jitsi-meet/issues/2894
,
Aug 15
,
Aug 15
Unlike other bugs this one indicates that window sharing is broken. Can you confirm that window sharing in Hangouts will start stream the whole merged desktop?
,
Aug 15
,
Aug 15
In Hangouts window sharing streams only one window, rather than the whole merged desktop. This is not the behavior I observed in Discord, which uses the chrome.desktopCapture API (potentially indirectly- it might make a call to Electron which calls desktopCapture). However, full screen sharing still streams the merged desktop in Hangouts (attached screengrab).
,
Aug 15
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 15
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by jamesgal...@gmail.com
, Aug 15