Thanks for the report. I'm Cc-ing dvadym@ and kolos@ who work on related improvements.

The last sentence of your report appears to be another bug: Chrome should let you change the username without discarding the filled password. I would like to try this out, but in a truly bureaucratic fashion, the site refuses to render the password form now, saying it would only do so during: "7:30 a.m. to 11:30 p.m. (local time within Canada and the U.S.)," whatever "local time withing Canada and the U.S." means. I'll try later today.

I had a chance to check out the form now.

The main issue is, unsurprisingly, confirmed, with Chrome not understanding which text field is supposed to be the "username". I support any improvement we can make, but, really, with forms like this, the web author should just mark the username field with autocomplete=username. If I understand this correctly, the username here is split over two fields, so we won't be able to fill completely anyway.

What I was not able to confirm, though, was that if you change the date (specifically, the "DD" part of "To", which is what Chrome autofills), that the password is then overwritten. In my case it stays autofilled. My Chrome version is 53.0.2785.30, OS is GNU/Linux, and I have been using chrome://flags/#enable-password-force-saving to save a fake credential for testing purposes.

Thanks for looking into this so promptly vabr@.

I'll confirm the details of the second part of the issue with the person who reported it to me and get back to you. I'll be sure to have them include their chrome version as well, but it's likely the latest stable release.

As to the first part, it might be an unrealistic expectation for us to be able to detect these obscure "username" fields, especially when they might consist of multiple fields. That said, what is perhaps the most prominent deterrent for autofill & password autofill usage alike is bad data. Thus, it'd be great to have better negative heuristics for knowing what fields are unlikely to be a username field (the date field in this case) if we don't have a positive heuristic for any field, and to not save such info at all.

Thanks!

If the second part (changing username erasing passwords) proves to be reproducible, that would likely be worth a separate bug, to keep this focused.

While I generally agree with your 3rd paragraph in #4, I'd keep decisions of how to act here to kolos@ and dvadym@, who already are working in this area.

Turns out that there was some miscommunication and only the first part of the issue occurred, the user did not have the password field cleared if it was manually entered and the date was changed.

Thanks.