Adding folks since this is a serious regression - Rahul, looks like SAML signin pages can no longer access the webcam. Specifically, looks like http://www.chromium.org/administrators/policy-list-3#LoginVideoCaptureAllowedUrls was broken (originally added here: https://codereview.chromium.org/1936903002).

kathrelkeld@: Do we have someone on test team with cycles to try to bisect?

Agree w/ priority as this breaks login for any schools using Clever badges on chromebooks.

Jacob, Alexander, Aga, Michael, could we have accidentally broken this?

Views-based login launched in m70, so I don't think was caused by the rewrite.

I can't remember any changes on our side that could affect this.

We're starting to get reports from Managed users on M71 Beta about being unable to log into their Chromebooks using Clever.

Reports with logs:
https://listnr.corp.google.com/report/85754276285
https://listnr.corp.google.com/report/85754135642
https://listnr.corp.google.com/report/85753872702
https://listnr.corp.google.com/report/85751987161
https://listnr.corp.google.com/report/85752609464

This does seem to be a regression on M71, as we have very few reports about Clever from users on pre-M71 builds.

Sounds a lot like https://bugs.chromium.org/p/chromium/issues/detail?id=797685#c6 (Permissions not getting passed through)

Unify: #17385909

We are starting to have EDU clients affected by this issue. 

=== NOTES ===

# Issue description: 
1) Customer reporting Clever badges is not working in Chrome OS 71.
They see the error message "Your browser does not support Clever badges. Login with your username and password" 
2) Issue did not occur in Chrome OS 69 or 70. 


All troubleshooting steps already taken: 
# I have advised to test it in 69 and 70, it was confirmed issue does not happen in these versions 
# Customer was advised to move the affected device to version 70 using the recovery tool and to pin the auto update version to 70 while issue is under investigation 
# behavior can re reproduced with different and unmanaged networks/different devices. 


Link to logs/policies/screenshots:

https://drive.google.com/open?id=1iCGkSj-bcvNDfkMW4Bq1d2OFIfGrvqRW

+ kbliecher, release manager for 71

Hopefully we can get a fix submitted soon and into a 72 beta refresh.

Pavol to take a look to help further triage.

Naveen, can you please reach out to test and ask for assistance with a bisect here?

I'll investigate today. A preliminary finding is that the request might be going through a WebContentsDelegate which does not override the CheckMediaAccessPermission method, and the default behavior is a rejection + a log message that appears in the linked logs. Might be a red herring though :) 

Here's what I found out:
- This originally didn't work under the "views-based sign-in"
  It was implemented in  bug 868188  by routing the CheckMediaAccessPermission/RequestMediaAccessPermission methods correctly.
  This relied on the fact that WebDialogView uses itself as the embedded WebContents' delegate[1] and nobody changes that for the OobeWebDialogView.
-  bug 871184  / specifically https://chromium-review.googlesource.com/c/chromium/src/+/1197785/ changed this.
  Now the OobeUIDialogDelegate is a WebContentsDelegate and sets itself as the OobeWebDialogView's WebContents' delegate[2]. This means that the functions introduced in  bug 868188  are never called.

I'd prefer to leave the WebDialogView delegate handling as it was previously, as WebDialogView has a few other overrides for WebContentsDelegate we may be skipping too, and instead move the TakeFocus/HandleKeyboardEvent handling from OobeUIDialogDelegate to OobeWebDialogView.

I'll see if that's possible and if yes will create a CL for this.

BTW, the regression browsertest SAMLPolicyTest::TestLoginMediaPermission didn't trigger because:
- It queries MediaCaptureDevicesDispatcher directly, while the real thing goes through the WebContentsDelegate set for the requesting WebContents
- All such tests currently use WebUI based login[3] 

[1] https://cs.chromium.org/chromium/src/ui/views/controls/webview/web_dialog_view.cc?gsn=WebDialogView&g=0&l=369 
[2] https://chromium.googlesource.com/chromium/src/+/3d7a0f0c6585089aa362aa08033a92bb7596590d/chrome/browser/chromeos/login/ui/oobe_ui_dialog_delegate.cc#205
[3] https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/test/oobe_base_test.cc?type=cs&sq=package:chromium&g=0&l=145

Issue 896005 has been merged into this issue.

As an FYI, we also have  crbug.com/902726  - camera fails to open on 2nd attempt with Dru devices. That issue occurs in 70 and we do not currently believe it's a dupe of this issue.

Re Comment #20: that looks unrelated indeed but also like something we should take a look at. It's possible that that particular issue doesn't break clever if it's really ARC++ related and thus only happens in a profile with ARC++ running (which would not be the sign-in profile). But I really don't know :) Let's discuss on that bug.

CL in review: https://chromium-review.googlesource.com/c/chromium/src/+/1323075

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

commit b7c509a505390c822463a33184e470a50a18b188
Author: Pavol Marko <pmarko@chromium.org>
Date: Wed Nov 07 19:16:09 2018

Use (Oobe)WebViewDialog as WebContentsDelegate for views-based oobe WebContents

Ensure that the OobeWebViewDialog is the WebContentsDelegate for the
WebContents used in views-based sign-in/OOBE. This fixes
camera access by SAML providers on the sign-in screen, because
the versions of CheckMediaAccessPermission/RequestMediaAccessPermission
forwarding to MediaCaptureDevicesDispatcher are invoked again.

Move focus/keyboard handling from OobeUIDialogDelegate to
OobeWebViewDialog to make changing the delegate unnecessary.

Background:
WebDialogView usually acts as the WebContentsDelegate for the
WebContents it embeds. CL:1178111 introduced the subclasss
OobeWebDialogView which customizes the WebContentsDelegate handling to
allow media requests.
CL:1197785 then exchanged the WebContents' delegate altogether to
implement keyboard/focus handling, orphaning the functions introduced in
CL:1178111. This CL moves the keyboard/focus handling to the
OobeWebDialogView and restores its function as WebContentsDelegate.

Bug:  900323 
Test: out/Default/browser_tests --gtest_filter=*SAMLPolicy*Test*TestLoginMedia*
Change-Id: I6c12b8b08efaa71a9f9cbb93d674448cdccbdeaf
Reviewed-on: https://chromium-review.googlesource.com/c/1323075
Commit-Queue: Pavol Marko <pmarko@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Quan Nguyen <qnnguyen@chromium.org>
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606111}
[modify] https://crrev.com/b7c509a505390c822463a33184e470a50a18b188/chrome/browser/chromeos/login/saml/saml_browsertest.cc
[modify] https://crrev.com/b7c509a505390c822463a33184e470a50a18b188/chrome/browser/chromeos/login/test/oobe_base_test.cc
[modify] https://crrev.com/b7c509a505390c822463a33184e470a50a18b188/chrome/browser/chromeos/login/test/oobe_base_test.h
[modify] https://crrev.com/b7c509a505390c822463a33184e470a50a18b188/chrome/browser/chromeos/login/ui/oobe_ui_dialog_delegate.cc
[modify] https://crrev.com/b7c509a505390c822463a33184e470a50a18b188/chrome/browser/chromeos/login/ui/oobe_ui_dialog_delegate.h

The fix above should be in >=72.0.3605.0

I'll leave the status of this bug on "Started" until a Merge CL to M71 has landed, and I'll request a merge after verification on M72.

When a build is available somewhere --

(*) Venkata, would you mind verifying if the fix is effective as you've done the verification on  bug 868188  ?
(*) Quan, would you mind checking if I haven't accidentally regressed  bug 871184  ?

Thanks!

Sure Pavol, I will verify once the build is available.

<Bulk edit> Reminder M71 Stable is approaching. Please review this bug and assess if this is indeed a RBS. If not, please remove the RBS label. If so, please make sure any planned work will be tested in Beta and verified before the Stable date. Thanks

Re Comment #26: I do think this should be RBS.
Waiting for a build to be available on canary for verificatiom before I'll add a merge request.

Observation : Camera turns on after reboot for QR badge login.

Google Chrome:72.0.3605.2 Platform: 11244.0.0 pantheon

Recorded video: https://drive.google.com/file/d/1rkzJe4ksuS5MgW0hTxq3Y-3Ik672N2Jp/view

Thanks a lot! When you say "after reboot", does this mean it didn't work before a reboot even with the new version? Or did you mean on the sign-in screen?

I meant it worked during Signin and even after device reboot as well :) 

Excellent, thanks for verifying!
Quan, would you mind checking if  bug 871184  is still OK on 72.0.3605.2? I don't feel qualified to tell.

Assuming everything is fine for now.

Requesting Merge of the CL in Comment #23 to M71 as verification was successful.

This bug requires manual review: M71 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Approved for M71 ChromeOS

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

commit 6e0348b7d49d4787bfa5b45c7de9a8920c6caf36
Author: Pavol Marko <pmarko@chromium.org>
Date: Sun Nov 11 21:12:15 2018

[Merge to M71] Use (Oobe)WebViewDialog as WebContentsDelegate for views-based oobe WebContents

Ensure that the OobeWebViewDialog is the WebContentsDelegate for the
WebContents used in views-based sign-in/OOBE. This fixes
camera access by SAML providers on the sign-in screen, because
the versions of CheckMediaAccessPermission/RequestMediaAccessPermission
forwarding to MediaCaptureDevicesDispatcher are invoked again.

Move focus/keyboard handling from OobeUIDialogDelegate to
OobeWebViewDialog to make changing the delegate unnecessary.

Background:
WebDialogView usually acts as the WebContentsDelegate for the
WebContents it embeds. CL:1178111 introduced the subclasss
OobeWebDialogView which customizes the WebContentsDelegate handling to
allow media requests.
CL:1197785 then exchanged the WebContents' delegate altogether to
implement keyboard/focus handling, orphaning the functions introduced in
CL:1178111. This CL moves the keyboard/focus handling to the
OobeWebDialogView and restores its function as WebContentsDelegate.

TBR=pmarko@chromium.org

(cherry picked from commit b7c509a505390c822463a33184e470a50a18b188)

Bug:  900323 
Test: out/Default/browser_tests --gtest_filter=*SAMLPolicy*Test*TestLoginMedia*
Change-Id: I6c12b8b08efaa71a9f9cbb93d674448cdccbdeaf
Reviewed-on: https://chromium-review.googlesource.com/c/1323075
Commit-Queue: Pavol Marko <pmarko@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Quan Nguyen <qnnguyen@chromium.org>
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#606111}
Reviewed-on: https://chromium-review.googlesource.com/c/1329789
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#628}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/6e0348b7d49d4787bfa5b45c7de9a8920c6caf36/chrome/browser/chromeos/login/saml/saml_browsertest.cc
[modify] https://crrev.com/6e0348b7d49d4787bfa5b45c7de9a8920c6caf36/chrome/browser/chromeos/login/test/oobe_base_test.cc
[modify] https://crrev.com/6e0348b7d49d4787bfa5b45c7de9a8920c6caf36/chrome/browser/chromeos/login/test/oobe_base_test.h
[modify] https://crrev.com/6e0348b7d49d4787bfa5b45c7de9a8920c6caf36/chrome/browser/chromeos/login/ui/oobe_ui_dialog_delegate.cc
[modify] https://crrev.com/6e0348b7d49d4787bfa5b45c7de9a8920c6caf36/chrome/browser/chromeos/login/ui/oobe_ui_dialog_delegate.h

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

Commit: 6e0348b7d49d4787bfa5b45c7de9a8920c6caf36
Author: pmarko@chromium.org
Commiter: pmarko@chromium.org
Date: 2018-11-11 21:12:15 +0000 UTC

[Merge to M71] Use (Oobe)WebViewDialog as WebContentsDelegate for views-based oobe WebContents

Ensure that the OobeWebViewDialog is the WebContentsDelegate for the
WebContents used in views-based sign-in/OOBE. This fixes
camera access by SAML providers on the sign-in screen, because
the versions of CheckMediaAccessPermission/RequestMediaAccessPermission
forwarding to MediaCaptureDevicesDispatcher are invoked again.

Move focus/keyboard handling from OobeUIDialogDelegate to
OobeWebViewDialog to make changing the delegate unnecessary.

Background:
WebDialogView usually acts as the WebContentsDelegate for the
WebContents it embeds. CL:1178111 introduced the subclasss
OobeWebDialogView which customizes the WebContentsDelegate handling to
allow media requests.
CL:1197785 then exchanged the WebContents' delegate altogether to
implement keyboard/focus handling, orphaning the functions introduced in
CL:1178111. This CL moves the keyboard/focus handling to the
OobeWebDialogView and restores its function as WebContentsDelegate.

TBR=pmarko@chromium.org

(cherry picked from commit b7c509a505390c822463a33184e470a50a18b188)

Bug:  900323 
Test: out/Default/browser_tests --gtest_filter=*SAMLPolicy*Test*TestLoginMedia*
Change-Id: I6c12b8b08efaa71a9f9cbb93d674448cdccbdeaf
Reviewed-on: https://chromium-review.googlesource.com/c/1323075
Commit-Queue: Pavol Marko <pmarko@chromium.org>
Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
Reviewed-by: Quan Nguyen <qnnguyen@chromium.org>
Reviewed-by: Jacob Dufault <jdufault@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#606111}
Reviewed-on: https://chromium-review.googlesource.com/c/1329789
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#628}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}

This has been merged to M-71, marking as Fixed.

Clever here. We’d love to help and verify that this fix resolves everything. Can anyone please advise on which ChromeOS version we should test?

Re Comment #37:
When you say everything, does this mean that you were experience additional issues to the Camera not being accessible on the sign-in screen?

The fix should be in a Chrome OS version >= 71.0.3578.49.
Kevin, do we have an option for Clever to test this other than waiting for >=71.0.3578.49 to reach Beta?

Re Comment #36: One valuable test would be trying this out on >= 72.0.3605.0 (which is currently on Canary but should be on Dev channel soon).

Kevin, friendly ping on if there's anything we can do to help Clever validate the fix on M-71 short of them waiting for it to reach beta.

Tyler, please email me direct and I can share a 71 build (let me know which chrome os devices) that you can test the fix on.

Hello,  I would be happy to test the M-71 if Clever has not yet.  I am the client that reported the issue to Clever.  10 of our first graders cannot log onto their chromebooks without this fix so that badges will work
.  LMK!  Carrie Bush Carolyn.bush@cr.k12.de.us 

Greetings.  I'd like to know if the fix has been tested in m-71 to update a technical case and request to test using Beta?

Regards

Thanks to help from Jay Lee, Clever was able to confirm that this change fixes Clever Badges in beta versions >= 71.0.3578.49.

Closing the issue as Verified as per #c44