Screenshare results in black screen with only mouse showing up.
Reported by
an...@techgentsia.com,
Dec 1 2017
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: 1. install ubuntu 17.10 2. install chrome 3. goto appear.in and start sharing your screen you will only get a black screen with mouse moving What is the expected behavior? you should get a the complete screen and not only the mouse What went wrong? capturing screen resulted in a black screen with mouse pointer in it. Did this work before? N/A Chrome version: 62.0.3202.94 Channel: stable OS Version: ubuntu 17.10 Flash Version:
,
Dec 6 2017
Unable to reproduce this issue on reported version 62.0.3202.94 using Ubuntu 14.04. Attaching screenshot for reference. 1. Navigated to https://appear.in/ and started screenshare and observed succesful screenshare without any blank screen. This might be specific to Ubuntu 17.10. As ET team doesn't have 17.10 could some one from Inhouse team take a look into this. Thanks!
,
Dec 6 2017
this is how this looks in ubuntu 17.10 , as you can see only the mouse pointer is showing up.
,
Dec 12 2017
Tested the issue on ubuntu 17.10 using chrome latest stable M63 #63.0.3239.84 and M65 #65.0.3292.0 and issue is reproduced. This issue is specific to ubuntu 17.10 and is reproduced from M57. Earlier versions of chrome has different behavior for appear.in. This is a Non-Regression issue and is marking it as untraiged for further updates on this. Thanks!
,
Dec 14 2017
,
Dec 14 2017
Yes, this is exactly same problem I just encountered on another Debian distribution, kernel 4.9. Seems that there's something new in the later kernels. Curious if it's reproducible on ubuntu 16.04(kernel 4.4) and ubuntu 16.10(kernel 4.8)?
,
Dec 22 2017
The root cause is a regression in XShmGetImage() in recent kernel releases, which has been fixed already. See https://bugs.freedesktop.org/show_bug.cgi?id=101730 for more details. The fix is here, https://cgit.freedesktop.org/xorg/xserver/commit/?id=885636b7d42b3c7b. No idea when this fix will be rolled into each affected Linux distribution. There are some ugly workaround available :) - align the target window to top-left of desktop, then the capture will work. - we can compensate the offset in XShmGetImage() with the real window location instead of "0,0" (which should be the offset within the target window). Surprisingly this method works on both older and newer/affected linux versions. But it violates the definitions of XShmGetImage() arguments. I think it's better not to do it. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by dtapu...@chromium.org
, Dec 4 2017