I think we need to clear SSLStatus::user_data on commit. Currently on commit we call updateSSLStatusForCurrentNavigation [1] where we end up resetting the content_status flags based on the mixed content status [2]. (I suspect this means there might be a second bug, where if you type in a form and then you do something else that triggers updateSSLStatusForCurrentNavigation without committing a new navigation, then the http-bad password flag gets cleared incorrectly.)

Maybe we should pass a flag into updateSSLStatusForNavigationItem that indicates whether the navigation item just committed, and if so clear user_data.

[1] https://cs.chromium.org/chromium/src/ios/web/web_state/ui/crw_web_controller.mm?type=cs&q=updateSSLStatusForCurrentNavigationItem&l=4632
[2] https://cs.chromium.org/chromium/src/ios/web/net/crw_ssl_status_updater.mm?type=cs&q=updateSSLStatusForNavigationItem+file:%5Esrc/ios/+package:%5Echromium$&l=77

By the way I don't think this should block the M65 experiment because it's an existing bug and visibility is very low (only the small % of iOS users who are opted in to this field trial).

Yeah, I found a few edge cases on iOS when testing Phase 2. I believe there was also a case where HB/Mixed Content warnings linger on back navigation, but these were arguably justified because the state of the page/form was also restored.

cthomp, does this bug matter more now as we are progressing forwards in # of red triangles shown?

Yes, it's probably a good idea to clear the downgraded indicator on reload (but not on history navigations, I think, as the form state is restored). I can look into how to best fix this (following on c#1).

(This behavior reproduces on the latest Chrome Dev on iOS (71.0.3577.0) with the new slim navigation manager enabled and the "mark with a Not Secure warning and dangerous on form edits" option for HTTP-Bad.)

Thanks, Chris

I've sent out an initial CL for review that fixes this: https://crrev.com/c/1292055

The latest version of the CL adds a check in InsecureInputTabHelper::DidFinishNavigation() to clear the input events flag and update the visible security state for the tab. Patchset 4 includes a check to not clear this for back/forward navigations, which can retain and restore the form state... sometimes. Brief testing shows that form state is restored for direct back/forward navigations, but not if you go back twice and then forward twice back to the page (testing on http://http-textarea.badssl.com/).

If there isn't a clear way to detect when form state was restored or not, then I think it would be best to not clear the input events data on these navigations. This would have us err on downgrading the indicator less often (even if some prior user entered text is in a form on the page) rather than over-zealously downgrade, which I think is a worthwhile tradeoff. If the user proceeds to make further form edits, then the indicator will be downgraded again. This behavior is implemented in the latest Patchset 5.

I'm going to double check with the iOS folks on whether it is possible to detect form state restoration with WKWebView (this might be implemented by that underlying system rather than by Chrome). If not, I'll go with the clear-on-back-forward option.

(Refresh currently does not restore form state on iOS Chrome, and is correctly handled in the latest patchset.)

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

commit 930d854cf147224c22fd413213fd2421f7111349
Author: Chris Thompson <cthomp@chromium.org>
Date: Fri Nov 02 23:32:22 2018

Clear SSL user data on committed navigations on iOS

This adds a |DidFinishNavigation| method to InsecureInputTabHelper, which
clears the SSL user data for committed navigations that aren't same-document
(where form input is still retained). When a user enters text in a form on
an HTTP page, the security state is downgraded to the "dangerous triangle"
icon -- clearing the SSL user data causes this state to correctly reset on
when reloading the page.

Bug:  810374 
Change-Id: I95456131689de9653688ab5d4061d338f92fa4e3
Reviewed-on: https://chromium-review.googlesource.com/c/1292055
Commit-Queue: Christopher Thompson <cthomp@chromium.org>
Reviewed-by: Eugene But <eugenebut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#605093}
[modify] https://crrev.com/930d854cf147224c22fd413213fd2421f7111349/ios/chrome/browser/ssl/insecure_input_tab_helper.h
[modify] https://crrev.com/930d854cf147224c22fd413213fd2421f7111349/ios/chrome/browser/ssl/insecure_input_tab_helper.mm
[modify] https://crrev.com/930d854cf147224c22fd413213fd2421f7111349/ios/chrome/browser/ssl/ios_security_state_tab_helper_unittest.mm