Vaclav: could you please take a look? If there are user-typed values, then only user-typed values should be considered. I believe issue happen due to changes in GetPasswordForm

Thanks for the report, Maxim.

I tried to bisect this and the result is:

https://chromium.googlesource.com/chromium/src/+log/8fe2c1269af42e4fd9257f09ef05762667331a7b..5fb6477979e1ff87938c3f592d10d9f7a2b65ec3

That one only has one autofill-related CL: https://crrev.com/c/1131457.

Not sure yet whether that's the real culprit, I start looking at the code now.

Strangely enough, reverting https://crrev.com/c/1131457 on ToT fixes this bug. Still not sure why.

Given that this is your CL, Maxim, I'm assigning to you. I'm happy to team up in figuring out what's wrong, though.

I think it is not the culprit. What range do you use? I don't understand why it is so small. 

Please don't revert the CL. I am going to merge it to Beta. 

The root cause of the bug is wrong server predictions:

The autofill server says that the field with name 'ctl00$cphMain$ctl00$ucRegisterFR$txtRegPasswordPlain' is the username (this is a plain-text field placed in DOM before the password field, which is used to cache the password value typed into the password field).

This is wrong, and the local heuristics produce a better guess.

Your CL is the culprit in the following sense: increasing the form size limit for queries results in sending request for this particular form (which happens to have 50 fields). This means that Chrome obtains the server response, and (even with the old form parser) overrides its own structural heuristics to choose the username.

This is, in particular, not an issue with the parser itself, and not something which was caused by the refactoring. We have bad data on the server and might want to also trace how it got there.

vabr going hobby only -> reducing involvement.
Please contact me directly in urgent matters.