Issue metadata
Sign in to add a comment
|
Incorrect Not Secure behavior on back navigation |
||||||||||||||||||||||||||
Issue descriptionChrome Version: 60.3112, 61.3161 OS: Windows 10 What steps will reproduce the problem? (1) Open DevTools console (2) Visit http://http-dynamic-login.badssl.com/ (3) Click Show Login Form (4) Observe "Not Secure" appears in omnibox and console shows HTTPBad warning ("This page contains ...") (5) Navigate to about:blank (6) Click Back OBSERVE: No "Not Secure" appears in the omnibox, but the console warning appears. Toggling the login form visibility at this point in debug causes a DCHECK. Presumably the problem here is that the security_info.displayed_password_field_on_http was set by !!(ssl.content_status & content::SSLStatus::DISPLAYED_PASSWORD_FIELD_ON_HTTP) which remained set on the NavigationEntry's SSLStatus even though the state of the markup on reload was different?
,
Jul 19 2017
The assert comes, I believe, from the fact that |DidFinishNavigation| sets logged_http_warning_on_current_navigation_ = false; without also setting time_of_http_warning_on_current_navigation_ = base::Time() The first time through |VisibleSecurityStateChanged|, we haven't actually finished the navigation yet. Navigation eventually finishes, the bool is cleared, and a future call to |VisibleSecurityStateChanged| finds that |time_of_http_warning_on_current_navigation_| is non-zero while |logged_http_warning_on_current_navigation_ | is false.
,
Jul 31 2017
,
Sep 25 2017
This doesn't repro in Chrome 63; the fix for Issue 750649 in SSLManager::DidCommitProvisionalLoad also clears the DISPLAYED_PASSWORD_FIELD_ON_HTTP bit. |
|||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||
Comment 1 by elawrence@chromium.org
, Jul 19 2017