New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Oct 2017
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

Chrome doesn't share its own windows in WebRTC screensharing sessions

Reported by, May 26 2017

Issue description

Chrome Version       : 58.0.3029.110
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)

What steps will reproduce the problem?
1. install chrome extension
2. open new chrome window (*not* tab, drag it to be new window) with some website
3. click blue extension icon, select this new window and wait for url to appear
4. open this url in new tab and see the result

What is the expected result?
What happens instead of that?

If you share new chrome window, screenshare wouldn't work. 
If you share entire screen or some other app, then it will work.

Please provide any additional information below:

I can reproduce this on Windows 7 and Window 10. Chromium 52 doesn't have this problem, this problem arised after recent automatic update of chrome.

This is chromium distribution which you can use for testing: 

UserAgentString: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Labels: Needs-Triage-M58
Components: Blink>WebRTC
Labels: Needs-Bisect

Comment 3 by, May 31 2017

Components: -Blink>WebRTC Blink>GetUserMedia>Desktop

Comment 4 by, May 31 2017

Labels: -Type-Bug -Pri-3 -Needs-Bisect M-60 hasbisect Pri-1 Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)
Tested the issue on windows 7 using chrome M58 #58.0.3029.110 and M60 #60.0.3115.0 and issue is reproduced.

Issue is broken in M58 and is reproduced only in windows ., and is regression issue

Good build: 58.0.3020.0(Revision: 451874).
Bad build: 58.0.3022.0 (Revision: 452713).

Unable to find the exact suspect from bisect script , tried in different machines and hence providing the manual chnagelog.

@could someone help us in assigning the issue to the concern owner.

Status: Assigned (was: Untriaged)
George, can you take a look? Seems related to the Aura window capturer on Windows.

Comment 6 by, May 31 2017

I tried with Windows 10 and Chrome 58.0.3029.110. 

When the same chrome windows is to be shared and displays the shared windows, this issue happens. If the tab that displays the shared chrome window is not in the same chrome window to be shared. Windows share works well.

Behavior of sharing and displaying at the same tab/window is undefined and is not a valid communication use case.

I will try on Windows 7 tomorrow.

Comment 7 by, May 31 2017

I tried with Windows 10 and Chrome 58.0.3029.110. 

I saw the the shared windows was always scale to display_area_width/share_windows_width for display. This may leads some part of shared window was cropped in the display. In order to show whole shared window, the scale should be min(display_area_width/share_windows_width, display_area_height/share_windows_height)

How to do display is controlled by JavaScript.

I tried chromium extension chromium\src\chrome\common\extensions\docs\examples\api\desktopCapture 
It works fine in both sharing and display.

Pleas let author check the JavaScript code in chrome extension for display part.

Comment 8 Deleted

Comment 9 by, May 31 2017

Besides the shared windows, shared screens were also always scaled to display_area_width/share_windows_width for display
gyzhou, do you want to say that the problem is because of bug in js code?
Crop issue is in both screen and windows capture and I think it is associated with JS code, since our test code in chromium\src\chrome\common\extensions\docs\examples\api\desktopCapture doesn't have this issue. We always use that test code to test desktop capture in the development.

However, you mentioned "If you share new chrome window, screenshare wouldn't work." which is no the crop issue. If the chrome window to be shared and to do display is the same, the display result may looks weird especially when crop issue exists. 
HI! I've used plugin from desktopCapture folder, which you have mentioned, in order to doublecheck the problem. I still can reprouce the problem.

As you can see, at first I am sharing screen of other app, which is my file manager and screensharing works perfect. But when I share screen of another chrome window ( website), I get blank white screen instead of picture.

I've recorded my experience for clarity here:

PS: I've reduced sizes of windows in this demo, because they were too large for my screen so I couldn't click the buttons.
Just tested with Windows 7 and chrome 58.0.3029.110 (64-bit)

Extension chromium\src\chrome\common\extensions\docs\examples\api\desktopCapture worked fine.

chrome extension crashed right after I clicked share button and a dialog box popped up in three different tries.

What window were you sharing when it worked?, if you are able to reproduce the issue, can you please test with chromium\src\chrome\common\extensions\docs\examples\api\desktopCapture ?
As in Comment 14, chromium\src\chrome\common\extensions\docs\examples\api\desktopCapture worked with a file explore window and a chrome window. I tested this case a couple of times.

chrome extension crashed in all three tries. I was not be able to share any window.

I was not able to reproduce the issue you reported initially.
I am able to reproduce this on Linux, 59.0.3071.86 (Official Build) (64-bit) as well as 61.0.3124.4 (Official Build) dev (64-bit) and 61.0.3135.4  like this:

- open and start video session
- choose ... -> share screen (if you are redirected to use "present" -> "a window" instead)
- pick window-> and choose the same chrome instance
- hangout preview stays empty. When choosing any other window, it'll show capture stream. (If you are on click on People->You, to view the stream)

Does not reproduce on Mac (61.0.3137.0)
I just tried chrome 59.0.3071.109 on linux and cannot reproduce the issue in comment 18. Screenshare worked fine with its own chrome window, another chrome window and a file explorer window.
I reproduce the issue on windows 10 and  chrome 59.0.3071.109 with  the extension mentionned  in comment 14.
I was able to shared my first screen but not the others (I've 3 screens)
Just re-tried to reproduce this with 59.0.3071.109 on Linux - still able to reproduce as described in comment 18. Works fine for any other window, except the same chrome instance. I.e. if I start another Chrome instance with --user-data-dir=XXXX, that one captured is fine too. Another profile user on the same chrome instance is not captured.

I'm running Ubuntu 16.04.2 LTS with unity. That's the output of chrome://gpu (if that's relevant):

Happy to provide any additional details as needed to track this down.
Thank you for the bug report.
There are different implementations for Windows 7- / Windows 8+ / Linux and MacOSX, so the issues may end up with different reasons.
For Windows (#c20), are you using a dock station with an external video card to attach the two more monitors? If so, this is a known issue which should be fixed in M60.
Chrome window is an aura window. Aura windows capture in Linux and windows (all version) uses the same mechanism. It is strange that some one see the chrome window sharing issue in Linux but not in Windows and vice versa.

Mac doesn't support aura window as I remember.
Labels: Needs-Feedback
 stiv.yakovenko@ can you please respond to #22?
zijiehe and anatolid, I don't know what you mean by dock station. I use this lenovo laptop with Windows 7 64bit:

I was able to reproduce it without connecting extra monitors, video of what i was seeing on desktop is recorded in comment #12. Should i retest it with some other chromium version?
Labels: -Needs-Feedback

Comment 27 by, Aug 16 2017

I could reproduce this on linux as well with 60.0.3112.101 (stable at the time of writing) and 61.0.3163.39 (beta).

However sharing a chrome stable window from a chrome beta session (and vice versa) works as intended.
Tried on 60.0.3112.101 on linux and following comment 18. I cannot reproduce this issue in my ubuntu machine.
Labels: -Pri-1 Pri-2
Labels: Needs-Feedback
Please let us know if this is a still an issue since we were unable to repro.
Is Chrome using hardware acceleration to render itself now?
(I see d3d libs are included in //media/gpu/, but I do lack enough knowledge about the rendering.)
If so, this looks like a known issue similar to
Just tested with Version 60.0.3112.113 (Official Build) (64-bit), the problem is still there.
Labels: -Needs-Feedback
I haven't been able to use Present > A window in Google Meet. I have HP Spectre x360 with an external Targus docking station connected through USB-C port to the laptop. The docking station has two monitors connected to it. 

When I try to present an application, Meet indicates that the application window is being shared, but the screen does not change and shows regular Meet window with participants. Only option that works is Present > Your entire screen.

Version 60.0.3112.113 (Official Build) (64-bit)

Happy to share additional information. 


I think you met this external docking issue before. Do you have any information of this.
Sharing Chrome window works on Win10, tested with Chrome M60&M61. Not sure about the docking stuff. timur@, does it work if you don't use docking station?

on Win7, sharing Chrome its own window use to work. But there is some problem with M61. I'll take another look.
It works with docking station unplugged.
Status: Fixed (was: Assigned)
It works on win7 with Canary now with fix to issue769979.

Since it also works with docking station unplugged. Mark fixed here.

Sign in to add a comment