Chromium

[Empty comment from Monorail migration]

alstrashkov@ Thanks for the issue.

As webcam is not available at TE end to test and confirm the issue, adding 'TE-NeedsTriageFromHYD'  label and requesting Inhouse team to look into the issue and help further.

Thanks..

[Monorail components: Blink>WebRTC]

Unable to reproduce the issue on Windows 10 (laptop) with chrome beta #77.0.3865.19 as per steps mentioned in https://crbug.com/chromium/992362#c0

Attaching the screen-cast for reference.

alstrashkov@ Could you please re-try the scenario on clean profile with no apps & extensions and let us know you observations...

[Empty comment from Monorail migration]

w.r.t https://crbug.com/chromium/992362#c3 - Link to the screen-cast  : https://drive.google.com/file/d/1nhvCg5slIi3ZzL_wHTCJeVfXMw2tTtq6/view?usp=sharing 

[Comment Deleted]

It is happening on my Windows 7 32 bits too.
Not happening on Windows 10 64 bits with the same camera.

Really, it works on Win 10. We have this problem only on Win 7.

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

Able to reproduce this issue on Windows 7  on Chrome Beta #77.0.3865.35 & Canary #78.0.3885.0
Issue regressed in M-77

Bisect Info :
==========
Good Build : 77.0.3862.0
 Bad Build   : 77.0.3863.0

Regression Range :
https://chromium.googlesource.com/chromium/src/+log/77.0.3862.0..77.0.3863.0?pretty=fuller&n=10000

Since TE doesn't have Win 7 machine with bisect script. providing manual suspect CL :
https://chromium.googlesource.com/chromium/src/+/826a54f5fac8bd605c30e3775f2303bca2b9860b

bryanf@ : Could you look into this issue...

[Empty comment from Monorail migration]

Thanks for the bisect & heads-up. I don't think the CL linked in https://crbug.com/chromium/992362#c10 should have affected getUserMedia behavior; it should have only affected getDisplayMedia behavior. (Its effects should be scoped to desktop/display capture, not impacting device/camera capture.)

There's another CL in the bisect regression range that moved & refactored the video capture service:
https://chromium.googlesource.com/chromium/src/+/2f8c1dd283a265c587267232577cbe8b5e6043aa

I wonder if that could have caused the regression. Could someone with bug-editing privileges please add the author of that CL to CC to take a look?

I haven't yet tried to bisect this further or debug it since I don't have easy access to a Win7 machine with a webcam device (only a Win7 VM I haven't been able to easily share the host machine's webcam with). I can try to set one up or experiment with virtual webcam software in the VM if necessary (e.g. if the perceived likelihood of that second CL being responsible is similarly low).

This is a duplicate of https://crbug.com/992328 . That's got narrower bisect info based on continuous builds. The regression range there excludes the first CL linked above & includes the second.

I was able to repro this in a Win7 VM using virtual webcam software. I've sent Ken (rockot@) some info on setting that up. (Win7 VM images may be downloaded from https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/ for limited-time testing.)

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

This issue was migrated from crbug.com/chromium/992362?no_tracker_redirect=1

[Multiple monorail components: Blink>WebRTC, Internals>Media]
[Monorail mergedwith: crbug.com/chromium/993204, crbug.com/chromium/995841]
[Monorail mergedinto: crbug.com/chromium/992328]
[Monorail components added to Component Tags custom field.]