A less impactful instance is at https://jbzdy.pl/. There the server also does not classify the username (it does classify a field as EMAIL_ADDRESS, but that's not a username and the new parser is correct to not understand it as such).

Here combining the password hints from the server with not so much structural analysis but with HTML username classifier would result in the best parsing.

However, there is no impact on jbzdy.pl, because this only affects the sign-up form, so is only relevant for saving (not filling), and that is done by the old parser so far. (We need to check what happens once we switch parsing for saving to the new one as well.)

Another instance: http://www.filelon.com/main/storage.php

Another instance: https://readms.net/

There the username on the sign-up form is not part of the server hints. On the upside, the server hints fix the classification of password fields.

Another instance: https://www.linkedin.com/ (also showing  bug 854130 ).

So, actually thinking about this a bit more, from the perspective of filling (not saving):

On all the sites listed here, other than https://sa2.53.com/vpn/index.html, the affected form is the sign-up form. And affected means that Chrome won't fill those, which is the correct behaviour.

On https://sa2.53.com/vpn/index.html, the form is a sign-in form, but contains two password fields (the second one for PIN). Not filling here is bad, and especially because Chrome does not even offer filling on demand.

It is hard to tell when a form has two password fields because it is a sign-up form, and when it has two because it is a sign-in with a PIN. And the latter case is likely to be a minority, so we should not necessarily optimise for it.

Chrome needs to decide what is what in the form, so pretending that a form only has a new-password field, but at the same time being prepared to fill a username and a stored password into different fields is not possible (in the current architecture).

One signal for knowing that a form is a sign-in form is the presence of saved credentials. And the fact that the server hints or autocomplete analysis only point out the new-password and nothing else is also suspicious -- a simple reset form should be small, if it has more structure, the analysis is likely wrong.

So I'm going to try to make a CL using those two signals, but am not holding my breath, because the information about what is stored is likely not available at the parsing time. Perhaps I could piggyback on the waiting we do for server predictions.

Some more thinking/details:

NewPasswordFormManager both has a FormFetcherImpl, and is currently waiting for 500ms for the server hints (kMaxFillingDelayForServerPerdictions) before parsing. It could just also wait for the PasswordStore results and pass to the parser whether there are any. The code changes are going to be moderate (something in NewPasswordFormManager and likely a lot in the tests). The cognitive complexity of the code will grow, for something which is an ad-hoc solution.

The most simple solution here is just to use the second signal: if the form looks complex but the analysis only found a new-password field, then the result is likely wrong and should be thrown away. This is still ad-hoc, but the code change will be smaller and the cognitive complexity will also not increase dramatically (not introducing a connection between previously unrelated areas such as PasswordStore and FormData parser).

Therefore, I will only go with the latter for fixing filling in M69.

For saving, we might need something other. I would be most happy if the server could just provide complete data in cases like these, leaving the client code simple.

CL implementing the fix for filling (https://crrev.com/c/1106167) is in review. Once landed, I will downgrade the priority, because the bug will only track the saving part.

The CL linked in #7 was abandoned, but the plan for now is https://crrev.com/c/1108209 for M69 and improving the server hints and/or votes Chrome sends later.

For future reference, this is what Chrome knew about the problematic form:

Server predictions: {
Signature of form: 15790261177054388659
Origin: https://sa2.53.com/
Action: https://sa2.53.com/
Form fields: 
login: 2301446952, type=text
passwd: 4260854359, type=password
passwd1: 3941545331, type=password, SERVER_PREDICTION: NEW_PASSWORD
}

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

commit 4f27fd28767a0b040cc75c6e4b713e1a1d6ba7a7
Author: Vaclav Brozek <vabr@chromium.org>
Date: Fri Jun 22 11:01:26 2018

Add filling fallback for new-password forms

Forms with only "new password" fields, i.e., fields which should
contain previously unknown passwords, are generally not to be filled.
A previously unknown password is unlikely to be among those stored
with Chrome.

However, due to errors in form field classification, it can happen
that despite Chrome's conclusion, the form actually contains fields
worth filling.

This CL makes it possible to fill such fields on-demand.

Bug:  854123 
Change-Id: I800290c4aabb91fb0fd661d083dc76af02c6895c
Reviewed-on: https://chromium-review.googlesource.com/1108209
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Reviewed-by: Dominic Battré <battre@chromium.org>
Cr-Commit-Position: refs/heads/master@{#569575}
[modify] https://crrev.com/4f27fd28767a0b040cc75c6e4b713e1a1d6ba7a7/chrome/renderer/autofill/password_autofill_agent_browsertest.cc
[modify] https://crrev.com/4f27fd28767a0b040cc75c6e4b713e1a1d6ba7a7/components/autofill/content/renderer/password_autofill_agent.cc
[modify] https://crrev.com/4f27fd28767a0b040cc75c6e4b713e1a1d6ba7a7/components/password_manager/core/browser/new_password_form_manager.cc
[modify] https://crrev.com/4f27fd28767a0b040cc75c6e4b713e1a1d6ba7a7/components/password_manager/core/browser/new_password_form_manager_unittest.cc

With r569575 we should be OK for 69. There is still the need to look into improving server-side signals about what forms are sign-up and what are not, mainly to ensure saving passwords work with the new parser.
For that, I'm downgrading the priority and remove the target milestone, because it does not need to be in 69.

Re-checking now shows:
https://sa2.53.com/vpn/index.html is the same in both parsers,
in https://jbzdy.pl/ the new parser gets the sign-up right (unlike the old parser) and they both get right the sign-in.