I've the same issue with chrome Version 59.0.3071.104 (Build officiel) (64 bits) on windows 10 64Bits.

WebRTC screen sharing only work with the first screen (I've 3 screen)

zijiehe, does this sound familiar?

@oleg.tlv.il-- Could you please provide us the sample extension url/test file and also please help us by providing the screencast of the steps to reproduce the issue , for better understanding.

Thanks!

Hi hdodda@chromium.org. I'm working on POC and unfortunately, i can't provide the url for you.

Attached screens of error result with two monitors:

1. ext.png - here you can see the extension script.
2. 1.png - share screen dialog (as you see i working with two monitors)
3. 2.png - here you can see constraints of getUserMedia.
4. 3.png - here you can see the error.

Attached screens with success result (one monitor):

1.1-screen-perm.png - share screen dialog (1 monitor)
2.1-screen-constraints.png - here you can see constraints of getUserMedia (1 monitor)
3.1-screen-success.png - here you can see the getUserMedia success.

 

Deleted: ext.png 37.6 KB

	ext.png 37.6 KB View Download

Deleted: 1.png 66.5 KB

	1.png 66.5 KB View Download

Deleted: 2.png 52.2 KB

	2.png 52.2 KB View Download

Deleted: 3.png 42.9 KB

	3.png 42.9 KB View Download

Deleted: 1-screen-perm.png 270 KB

	1-screen-perm.png 270 KB View Download

Deleted: 1-screen-constraints.png 362 KB

	1-screen-constraints.png 362 KB View Download

Deleted: 1-screen-success.png 558 KB

	1-screen-success.png 558 KB View Download

Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

There is no enough test case available to provide bisect for this issue, Hence removing bisect label. 

Observing similar WebRTC issue ( Bug 726664 ), cc'ing @gyzhou for more updates.

gyzhou@ Could you please take a look in to this issue?

Thanks!

Thank you for the bug report.
Are you using a dock station to attach the two more monitors? If so, this is a known issue which should be fixed in M60.

Hi zijiehe. Yes, i using dock station. Good to know. We will wait for fix. Thanks

Same here, I used a dell dock station which connect with 2 monitors, couldn't share screen for these 2 monitors, but I can share the screen of my laptop.
Does M60 means next version of Chrome - v60 after current version v59?

Yes, M is short for milestone.
If it's not complex, would you mind to try the beta channel of Chrome at https://www.google.com/chrome/browser/beta.html, to see if there may be any other issues to block the monitors connecting to the dock from being captured?

Thank you.

This is not complex, i glad to help. i'll let you know if i will find some issues with dock on beta.

Regarding c#10, ( Bug 726664 ) is associated with chrome windows capture. Chome window capture (aura window capture) and screen capture use total different mechanisms.

I can reproduce this bug on chrome 60 (beta) with two monitors and dell dock station D3000.

Thank you for the information. Something else may be wrong. I will try to reproduce locally.

I have received reports of a very similar or identical bug from users of CrankWheel. They are using Windows 10, and right on the Chrome 59 update is when the problem started. Am waiting to hear back whether they are using a docking station, how many monitors they have, and other information that possibly might help isolate the issue. I will see if they can also test on the Beta channel to see if that fixes things for them.

Updates from CrankWheel users, at least two users at one company:
- They are _not_ using docking stations.
- They are on Windows 10.
- They have two monitors attached to a regular desktop tower. No laptop.
- Rolling back to 58 (Chromium Portable) fixes the problem.
- Switching to Chrome 60 (beta channel) does not fix the problem; same behavior (no media stream after selecting a monitor to share in the picker and clicking 'Share').

I could ask for details of their monitor types, graphics cards / drivers, etc. just let me know what details might be helpful.

Thank you for the information.
I am now working on a change which fixes an issue of inconsistent source id (https://codereview.chromium.org/2961193002/). Once the change is submitted, would you mind to ask them to try canary channel if it fixes their issue.
Graphics cards and drivers are important.

We are experiencing the same issue on Chrome after upgrade to v59. It happens on Windows 10.

- 3 monitors connected:
When I connect 3 monitors I get a mismatch from which screen user selects to share and which actually gets shared. User selects screen 1 but screen 2 gets shared.

- 2 monitors connected:
When I connect only 2 monitors and share screen 1 - screen 2 gets shared. When I select to share screen 2 I get an error code 1500: "Session.publish :: The selected voice or video devices are unavailable. Verify that the chosen devices are not in use by another application. (getUserMedia error: TrackStartError)"

@zijiehe, re #c22, I am waiting for details of the graphics card / drivers. Also, their initial report was that rolling back to 58 fixed the issue, but they now report that although things seem to work after that rollback, their viewers now see a white video frame (instead of there being an error). This could be because the rollback was to a different Chromium version than the latest 58 version, I'm not sure (we gave them Chromium Portable 58.0.3029.5 as a workaround, perhaps there is a better way to try "official" Chrome 58?)

Re #c24, another user at the same company is experiencing the issue described by @vkulov with 2 monitors connected, i.e. the opposite screen ges shared and they can't share all screens. When they rearranged their screens (in the Displays control panel) so that screen 2 is to the right-hand-side of screen 1, then they were able to share either screen but the thumbnails in the getUserMedia picker dialog were switched compared to the screen order and compared to the screen they selected.

I don't know if this is the same bug or different but it seems quite related as I believe the two users are on similar setups. I can provide screen shots and more details on the invertedness of the picker, etc., please let me know if this is desired.

The user in question (2 monitors) has the following setup, I'm waiting for video driver information:

Google Chrome Version 59 (64 Bit) 
Windows 10 Professional (64 Bit)
ASUSTeK COMPUTER INC. B85M-E
Intel Core i5-4460 CPU @ 3.20GHz
NVIDIA GeForce GT 730 2.0 GB

Details of two affected PCs:

PC D - the 2 monitor issue described by @vkulov:

Google Chrome Version 59 
Windows 10 Professional (64 Bit)
ASUSTeK COMPUTER INC. B85M-E
Intel Core i5-4460 CPU @ 3.20GHz
NVIDIA GeForce GT 730 2.0 GB – (22.21.13.8205 - 01/05/2017)

PC I - Same Chrome and CrankWheel version, but is unable to share full screen at all (and with Chromium Portable 58.0.3029.5 seems to share successfully but we just get a blank white video stream):

Google Chrome Version 59 
Windows 10 Professional (64 Bit)
Gigabyte Technology Co., Ltd. B75M-D3P (rev 1.1)
Intel Core i5-3330 CPU @ 3.00GHz
NVIDIA GeForce GT 730 2.0 GB – (21.21.13.7878 - 23/02/2017)

The video cards are the same but there is a slight difference in the NVIDIA drivers.

Hi, is there any update on this issue? We are getting more and more reports of users who are affected. I'm not sure it's all the same bug, but so far after 59 went out, we are getting reports of not being able to share full screen at all, or Chrome being confused about which screen is which and sharing the one other than the one you picked. I also have one report of Chrome sharing the other screen than the one you picked, but showing the mouse cursor position from the screen you picked (and not updating the mouse when you move it on the screen actually being shared).

If there is anything the CrankWheel team can do to help other than provide information for the bug? I would be willing to put resources to work on this issue, if you point us in the right direction. Even if it is just to set up a test environment where this reproduces and be able to help reproduce or check potential fixes. Let me know how we can help.

Also: Is there a flag that can be set to revert to the older screen capturer, as a workaround for folks affected by this?

From the user whose mouse cursor is grabbed from the other screen than the one being shared, I heard from him that he had this problem temporarily a couple of months ago, which I'm pretty sure coincides with the first attempt at turning on the new screen capturer, which was subsequently abandoned. The problem then started again and coincides with his machine updating to Chrome 59.

I am talking with Niklas whether we should revert the change of enabling new capturer.

Talked offline with Niklas (niklase@), I will disable new capturer soon. Customers need to restart their browsers to take effect. I will let you know once the configuration has been pushed.

And Joi, how many users cannot share full screen at all?

The configuration has been pushed. After restarting browser entirely, users should be able to use old capturer.

I have just confirmed, the defect of screen sharing feature on devices with dock station can also be fixed by https://codereview.chromium.org/2961193002/.

@zijiehe, thanks for this.

Only one confirmed report (on Win10) of not being able to share screen at all (at least one other report on Linux but I think that's unrelated). Also only one report regarding the mouse cursor from one screen (the one selected) being grabbed while video was grabbed from a different screen (the one other than the one selected). The most frequent report was of sharing a different screen than requested and only being able to share primary screen.

Since this seems to be very hardware-dependent, if/when you want to try some fixes of the new capturer, I have at least three users who seem quite motivated that I could probably get to try out some Canary or Dev builds with fixes. This group of users includes the ones who had the less common problems of being unable to share screen at all, and the mouse cursor thing.

@zijiehe: I could not find any flag to disable it. Can the new capturer be disabled by domain policy or commandline switch by affected users as a workaround?

In terms of the issue "Chrome being confused about which screen is which and sharing the one other than the one you picked", it is fixed on my Surface device now. However, when I connect my Surface with one monitor, it shows three screens for me to select (1+1=2 not 3). The extra screen seems like a repeat screen of the other two. This issue seems not completely fixed. Feel free to message me if you wanna more information to do the fix

Thank you for the information shared with us.
RE #c34, there is not a flag to disable it, but we can control it through Chrome experiment system.
RE #c36, have you seen the similar issue when using M58? Ideally the behavior of screen capturing now should be consistent with M58.

RE #c33. That's really helpful.
Linux uses a totally different implementation, which should not relate to screen capturer for Windows.

I am working on change https://codereview.chromium.org/2961193002/, which is at least the root cause for two issues mentioned in this bug: 1) cannot share monitors attached to a dock station. 2) share a wrong monitor. After the change has been submitted, would you mind to try the latest Canary build (https://www.google.com/chrome/browser/canary.html)? The canary build uses a totally different profile location, so it won't impact existing Chrome installations.

I am still investigating the root cause of unable to share screen at all. Though it may also relate to https://codereview.chromium.org/2961193002/. If you may also try the canary build on the specific device, that would be even more helpful.

One more issue has been detected regarding to the incorrect position of mouse cursor when sharing screen, which is tracked at https://bugs.chromium.org/p/webrtc/issues/detail?id=7950.

Thank you.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/56efe642b5d1fc400ac7f34451d9a540f9d30fbb

commit 56efe642b5d1fc400ac7f34451d9a540f9d30fbb
Author: zijiehe <zijiehe@chromium.org>
Date: Fri Jul 07 23:26:16 2017

Use same DesktopCaptureOptions in DesktopCaptureBase and DesktopCaptureDevice

DesktopCaptureOptions impacts which underlying DesktopCapturer implementation is
used. But there is no guarantee that different DesktopCapturer implementations
would eventually return the same SourceList, or a Source in the SourceList
represents the same output content on the system. So DesktopCaptureBase and
DesktopCaptureDevice should use same DesktopCaptureOptions.

BUG= 732224 

Review-Url: https://codereview.chromium.org/2961193002
Cr-Commit-Position: refs/heads/master@{#485097}

[modify] https://crrev.com/56efe642b5d1fc400ac7f34451d9a540f9d30fbb/chrome/browser/extensions/api/desktop_capture/desktop_capture_base.cc
[modify] https://crrev.com/56efe642b5d1fc400ac7f34451d9a540f9d30fbb/content/browser/media/capture/desktop_capture_device.cc
[modify] https://crrev.com/56efe642b5d1fc400ac7f34451d9a540f9d30fbb/content/public/browser/BUILD.gn
[modify] https://crrev.com/56efe642b5d1fc400ac7f34451d9a540f9d30fbb/content/public/browser/DEPS
[add] https://crrev.com/56efe642b5d1fc400ac7f34451d9a540f9d30fbb/content/public/browser/desktop_capture.cc
[add] https://crrev.com/56efe642b5d1fc400ac7f34451d9a540f9d30fbb/content/public/browser/desktop_capture.h

Change in #c39 needs to be merged to M60.

@zijiehe, re #c38, happy to ask some of the users to test the new canary.

I see your change has landed. I'm going to assume that it's OK to ask them to test Canary on Monday. Let me know if that assumption is wrong, otherwise expect to hear back from me soon after that.

Thank you Joi. Yes, the latest canary build should be updated in daily basis.
https://bugs.chromium.org/p/webrtc/issues/detail?id=7950 has not been fixed yet. So users may still not be able to see the mouse cursor on the secondary or third monitors.

This bug requires manual review: DEPS changes referenced in bugdroid comments.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Version 61.0.3152.0 (Official Build) canary (64-bit) - works fine with dock station and two monitors.

Approved merge to M60. 

Please merge this to M60 ASAP. branch:3112

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf819e8a3d126f2a68bc631d89bb48a308ef6d50

commit bf819e8a3d126f2a68bc631d89bb48a308ef6d50
Author: Zijie He <zijiehe@chromium.org>
Date: Mon Jul 10 18:01:47 2017

Use same DesktopCaptureOptions in DesktopCaptureBase and DesktopCaptureDevice

DesktopCaptureOptions impacts which underlying DesktopCapturer implementation is
used. But there is no guarantee that different DesktopCapturer implementations
would eventually return the same SourceList, or a Source in the SourceList
represents the same output content on the system. So DesktopCaptureBase and
DesktopCaptureDevice should use same DesktopCaptureOptions.

BUG= 732224 

Review-Url: https://codereview.chromium.org/2961193002
Cr-Original-Commit-Position: refs/heads/master@{#485097}
(cherry picked from commit 56efe642b5d1fc400ac7f34451d9a540f9d30fbb)
Review-Url: https://codereview.chromium.org/2979563002 .
Cr-Commit-Position: refs/branch-heads/3112@{#560}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/bf819e8a3d126f2a68bc631d89bb48a308ef6d50/chrome/browser/extensions/api/desktop_capture/desktop_capture_base.cc
[modify] https://crrev.com/bf819e8a3d126f2a68bc631d89bb48a308ef6d50/content/browser/media/capture/desktop_capture_device.cc
[modify] https://crrev.com/bf819e8a3d126f2a68bc631d89bb48a308ef6d50/content/public/browser/BUILD.gn
[modify] https://crrev.com/bf819e8a3d126f2a68bc631d89bb48a308ef6d50/content/public/browser/DEPS
[add] https://crrev.com/bf819e8a3d126f2a68bc631d89bb48a308ef6d50/content/public/browser/desktop_capture.cc
[add] https://crrev.com/bf819e8a3d126f2a68bc631d89bb48a308ef6d50/content/public/browser/desktop_capture.h

Thank you Oleg.
The change has been merged to M60 by change https://codereview.chromium.org/2979563002. This change is manually merged due to the conflict of desktop_capture_base.cc file. Please let me know if anything else I need to do for this change.

I heard back from two CrankWheel customers who had been affected by this bug, who have since tried the Canary build on the same machines.

One of them had the problem where screens were switched/confused (but not the mouse cursor problem). The other had the problem where they were unable to initiate full screen sharing at all.

Both report that these problems are no longer occurring on the Canary.

I would very much like to help ensure that M60 goes out smoothly without new issues in the screen capturer. What would you recommend, should I e.g. ask the previously affected customers to switch to Beta channel until M60 becomes stable, so we get some more coverage of the fixes?

That would be awesome, 60 has the new capturer enabled and should have all known issues fixed except one: https://bugs.chromium.org/p/webrtc/issues/detail?id=7950. We don't consider that one a blocker for 60.

FYI, a fix of the https://bugs.chromium.org/p/webrtc/issues/detail?id=7950 has been submitted. You may also try latest canary build maybe two days later to verify it. (The change is in WebRTC, so it needs to be merged to Chromium first.)

What's the latest status here? Is this fixed now?

This bug won't reproduce on my machine. But I believe we are waiting for Joi's response.
I will resolve the bug as fixed. Feel free to reopen it if the issue still exists.

 Issue 737998  has been merged into this issue.

The following revision refers to this bug:
  https://webrtc.googlesource.com/src.git/+/6564ea3b46ac9cb1a3f59d4d39350edcaf7fdc4d

commit 6564ea3b46ac9cb1a3f59d4d39350edcaf7fdc4d
Author: Zijie He <zijiehe@google.com>
Date: Thu Sep 14 17:10:09 2017

FallbackDesktopCapturerWrapper should set permanent_error if main_capturer_->SelectSource() failed

 http://crbug.com/732224  should be able to be covered by
FallbackDesktopCapturerWrapper if its SelectSource() behaves like this.

This change also adds histogram to track the failure of SelectSource().

This change was reviewed at
https://chromium-review.googlesource.com/c/external/webrtc/+/662906.

Bug:  chromium:732224 
Change-Id: I6cffe745a48d77acb703bfb0a0d042b170d8a937
TBR: jamiewalch@chromium.org
Reviewed-on: https://webrtc-review.googlesource.com/1380
Reviewed-by: Zijie He <zijiehe@google.com>
Commit-Queue: Zijie He <zijiehe@google.com>
Cr-Commit-Position: refs/heads/master@{#19839}
[modify] https://crrev.com/6564ea3b46ac9cb1a3f59d4d39350edcaf7fdc4d/webrtc/modules/desktop_capture/fallback_desktop_capturer_wrapper.cc