Form-Not-Secure doesn't always work on page load |
|||||
Issue descriptionChrome Version: 57.0.2964.0 OS: Mac but have also been able to reproduce on Linux What steps will reproduce the problem? (1) Visit http://rsolomakhin.github.io/autofill/ and save a username/password in the Name/Password form. (2) Enable "Fill passwords on account select" in chrome://flags and relaunch Chrome. (3) Navigate to http://rsolomakhin.github.io/autofill/. What is the expected result? Autofill dropdown appears in the Name/Password form on page load. What happens instead? Occasionally, the dropdown does not show up. It's a bit hard to reproduce; I seem to have the best luck when I navigate directly to http://rsolomakhin.github.io/autofill/ upon opening the browser. I ran into this (and will need to fix) as part of working on issue 672668 . I've debugged a little bit and it seems like some events that can cause the autofill popup to hide itself can come in after the fill-on-account-select flow kicks in. For example, I've seen a RenderWidgetWasResized message come in after the autofill popup is shown in a few instances; the RenderWidgetWasResized messages hides the autofill popup.
,
Dec 30 2016
,
Dec 30 2016
Poking around at this a bit, one possible way to fix might be to always early-return in ChromeAutofillClient::MainFrameWasResized if |width_changed| is false. (Currently we only early-return in that case on Android.)
,
Jan 4 2017
,
Jan 4 2017
,
Jan 10 2017
Update after poking around a bit more (mostly notes for self): I think this might be triggered by infobars/bookmark bar on the NTP. When that info disappears on navigation, the main frame is reported to have resized, and that resize message can come after the autofill popup is shown.
,
Jan 26 2017
We decided not to show the FNS warning on page load due to bugginess. This will still need to be fixed for fill-on-account-select though. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by vabr@chromium.org
, Dec 28 2016