Recognise first hinted new-password field

The FormData -> PasswordForm parser can see multiple hints from the
server that a field is a new-password field. In particular, this
happens if those fields have the same signature. The parser only can
choose one new-parser field, and on that field, password generation is
offered. If this is any other than the first field, the user has
likely already thought of and typed their new password elsewhere.

Therefore, this CL makes sure that the first hinted new-password field
is marked as such by the parser.

Bug: 902700
Change-Id: Idb065e7391526036347feb586b2a702d74f431a9
Reviewed-on: https://chromium-review.googlesource.com/c/1325986Reviewed-by: Dominic Battré <battre@chromium.org>
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#606430}

components/password_manager/core/browser/form_parsing/form_parser.cc

@@ -224,8 +224,16 @@ std::unique_ptr<SignificantFields> ParseUsingPredictions(
         // password, the first username is understood as sign-up, not sign-in.
         if (!result->password)
           sign_in_username_first = false;
-        result->new_password =
-            FindFieldWithUniqueRendererId(processed_fields, prediction.first);
+
+        // If multiple hints for new-password fields are given (e.g., because
+        // of more fields having the same signature), the first one should be
+        // marked as new-password. That way the generation can be offered
+        // before the user has thought of and typed their new password
+        // elsewhere. See https://crbug.com/902700 for more details.
+        if (!result->new_password) {
+          result->new_password =
+              FindFieldWithUniqueRendererId(processed_fields, prediction.first);
+        }
         break;
       case CredentialFieldType::kConfirmationPassword:
         result->confirmation_password =

components/password_manager/core/browser/form_parsing/form_parser_unittest.cc

@@ -1586,11 +1586,11 @@ TEST(FormParserTest, MultipleUsernames) {
               {.role_filling = ElementRole::USERNAME,
                .form_control_type = "text",
                .prediction = {.type = autofill::USERNAME}},
-              {.form_control_type = "password",
-               .prediction = {.type = autofill::ACCOUNT_CREATION_PASSWORD}},
               {.role = ElementRole::NEW_PASSWORD,
                .form_control_type = "password",
                .prediction = {.type = autofill::ACCOUNT_CREATION_PASSWORD}},
+              {.form_control_type = "password",
+               .prediction = {.type = autofill::ACCOUNT_CREATION_PASSWORD}},
               {.role = ElementRole::CURRENT_PASSWORD,
                .form_control_type = "password",
                .prediction = {.type = autofill::PASSWORD}},
@@ -1617,6 +1617,29 @@ TEST(FormParserTest, MultipleUsernames) {
   });
 }
 
+// If multiple hints for new-password fields are given (e.g., because of more
+// fields having the same signature), the first one should be marked as
+// new-password. That way the generation can be offered before the user has
+// thought of and typed their new password elsewhere. See
+// https://crbug.com/902700 for more details.
+TEST(FormParserTest, NewPasswordFirst) {
+  CheckTestData({
+      {
+          "More than two usernames are ignored.",
+          {
+              {.role = ElementRole::USERNAME,
+               .form_control_type = "text",
+               .prediction = {.type = autofill::USERNAME}},
+              {.role = ElementRole::NEW_PASSWORD,
+               .form_control_type = "password",
+               .prediction = {.type = autofill::ACCOUNT_CREATION_PASSWORD}},
+              {.form_control_type = "password",
+               .prediction = {.type = autofill::ACCOUNT_CREATION_PASSWORD}},
+          },
+      },
+  });
+}
+
 TEST(FormParserTest, HistogramsForUsernameDetectionMethod) {
   struct HistogramTestCase {
     FormParsingTestCase parsing_data;