Proxy requiring authentication does not show up in views login |
||||||||||
Issue description1. Connect to a network that requires proxy 2. Configure proxy 3. Try to add a user; gaia is effectively frozen because the username/password box that appears is likely rendering behind the login UI.
,
Oct 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/38e53d43e41a5e6309222ffdf8d0a1d9637c5d58 commit 38e53d43e41a5e6309222ffdf8d0a1d9637c5d58 Author: Jacob Dufault <jdufault@google.com> Date: Thu Oct 04 21:36:37 2018 cros: Temporary fix to show ProxyBasicAuth prompt on views-login. When the basic auth widget appears, it is fetching the parent widget using WebContentsModalDialogHost::GetHostView. CaptivePortalDialogDelegate overrides this to return the captive portal widget, which is hidden. Thus, the auth widget is also hidden because its parent widget is hidden. I believe the correct long-term fix is to not share a WebContents instance bewteen OoobeUIDialogDelegate and CaptivePortalDialogDelegate. However, that seems like a much riskier change. Add a hacky check to return the widget for OoobeUIDialogDelegate if the CaptivePortalDialogDelegate widget is currently hidden. Bug: 890976 Change-Id: I0d974449d7eb425a8bb99dcc8d34eb6582c097e7 Reviewed-on: https://chromium-review.googlesource.com/c/1263040 Reviewed-by: Quan Nguyen <qnnguyen@chromium.org> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Commit-Queue: Jacob Dufault <jdufault@chromium.org> Cr-Commit-Position: refs/heads/master@{#596865} [modify] https://crrev.com/38e53d43e41a5e6309222ffdf8d0a1d9637c5d58/chrome/browser/chromeos/login/ui/oobe_ui_dialog_delegate.cc
,
Oct 4
,
Oct 4
,
Oct 4
This bug requires manual review: We are only 11 days from stable. Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 5
This issue is marked as a release blocker with no OS labels associated. Please add an appropriate OS label. All release blocking issues should have OS labels associated to it, so that the issue can tracked and promptly verified, once it gets fixed. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 5
,
Oct 5
,
Oct 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b01aa4f4f1b31f449476d2c70859964f9bbdbb07 commit b01aa4f4f1b31f449476d2c70859964f9bbdbb07 Author: Jacob Dufault <jdufault@google.com> Date: Fri Oct 05 17:46:37 2018 cros: Temporary fix to show ProxyBasicAuth prompt on views-login. When the basic auth widget appears, it is fetching the parent widget using WebContentsModalDialogHost::GetHostView. CaptivePortalDialogDelegate overrides this to return the captive portal widget, which is hidden. Thus, the auth widget is also hidden because its parent widget is hidden. I believe the correct long-term fix is to not share a WebContents instance bewteen OoobeUIDialogDelegate and CaptivePortalDialogDelegate. However, that seems like a much riskier change. Add a hacky check to return the widget for OoobeUIDialogDelegate if the CaptivePortalDialogDelegate widget is currently hidden. TBR=jdufault@google.com (cherry picked from commit 38e53d43e41a5e6309222ffdf8d0a1d9637c5d58) Bug: 890976 Change-Id: I0d974449d7eb425a8bb99dcc8d34eb6582c097e7 Reviewed-on: https://chromium-review.googlesource.com/c/1263040 Reviewed-by: Quan Nguyen <qnnguyen@chromium.org> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Commit-Queue: Jacob Dufault <jdufault@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#596865} Reviewed-on: https://chromium-review.googlesource.com/c/1265159 Reviewed-by: Jacob Dufault <jdufault@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#875} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/b01aa4f4f1b31f449476d2c70859964f9bbdbb07/chrome/browser/chromeos/login/ui/oobe_ui_dialog_delegate.cc
,
Oct 5
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b01aa4f4f1b31f449476d2c70859964f9bbdbb07 Commit: b01aa4f4f1b31f449476d2c70859964f9bbdbb07 Author: jdufault@google.com Commiter: jdufault@chromium.org Date: 2018-10-05 17:46:37 +0000 UTC cros: Temporary fix to show ProxyBasicAuth prompt on views-login. When the basic auth widget appears, it is fetching the parent widget using WebContentsModalDialogHost::GetHostView. CaptivePortalDialogDelegate overrides this to return the captive portal widget, which is hidden. Thus, the auth widget is also hidden because its parent widget is hidden. I believe the correct long-term fix is to not share a WebContents instance bewteen OoobeUIDialogDelegate and CaptivePortalDialogDelegate. However, that seems like a much riskier change. Add a hacky check to return the widget for OoobeUIDialogDelegate if the CaptivePortalDialogDelegate widget is currently hidden. TBR=jdufault@google.com (cherry picked from commit 38e53d43e41a5e6309222ffdf8d0a1d9637c5d58) Bug: 890976 Change-Id: I0d974449d7eb425a8bb99dcc8d34eb6582c097e7 Reviewed-on: https://chromium-review.googlesource.com/c/1263040 Reviewed-by: Quan Nguyen <qnnguyen@chromium.org> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org> Commit-Queue: Jacob Dufault <jdufault@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#596865} Reviewed-on: https://chromium-review.googlesource.com/c/1265159 Reviewed-by: Jacob Dufault <jdufault@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#875} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
,
Oct 5
Removing RBS and moving to 71 for the full fix.
,
Jan 4
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by jdufault@chromium.org
, Oct 1