[Password manager] Recognise squashed login+sign-up forms

components/autofill/core/common/password_form.h

Index: components/autofill/core/common/password_form.h
diff --git a/components/autofill/core/common/password_form.h b/components/autofill/core/common/password_form.h
index 783eda54786c8e433d20807d7799e65c5523b62b..e927485e71393d8f4f8dcf10a4dc3b117367de2d 100644
--- a/components/autofill/core/common/password_form.h
+++ b/components/autofill/core/common/password_form.h
@@ -59,6 +59,24 @@ struct PasswordForm {
     SCHEME_LAST = SCHEME_OTHER
   } scheme;
 
+  // A layout characterises the sequence of non-password text and password input
+  // fields of which the form is made. It is defined as a regular language over
+  // the alphabet {N, P} (indicating Non-password and Password fields); e.g., a
+  // layout NPN+PP characterises all forms which have a single non-password
+  // field followed by a single password field, followed by 1 or more
+  // non-password fields, followed by 2 password fields.
+  // For most forms we do not care about the layout (those have LAYOUT_OTHER),
+  // but for special cases we might need to know it: e.g., the NPN+PP forms can
+  // be a login form glued to a sign-up form, and the "N+" part is what
+  // distinguishes such forms from change-password forms.
+  // A layout is useful for understanding parsed forms and deciding whether to
+  // fill them, but it is not stored.

[Garrett Casto, 2015/03/17 22:49:37]

This comment seems like more information than is necessary. Consumers of this
data don't necessarily need to care about exactly how exactly the form is laid
out for a form to be classified as LAYOUT_LOGIN_AND_SIGNUP, they just need to
know what it means. I would drop the discussion of regular expression and what
sequence needs to be matched and just talk generally about how these forms are
different.

If you want to keep technical discussion about how we determine Layout, keeping
it in PasswordFormConversionUtils seems more reasonable. Some discussion about
how we determined the current regexp seems like it could be useful (e.g. didn't
use ".*PN+P.*" since it would match signup forms which use password fields to
store private but non-password data).

[vabr (Chromium), 2015/03/18 16:51:03]

Good point, I tried to rephrase.

+  enum class Layout {
+    LAYOUT_OTHER,
+    LAYOUT_LOGIN_AND_SIGNUP,  // NPN+PP
+    LAYOUT_LAST = LAYOUT_LOGIN_AND_SIGNUP
+  };
+
   // The "Realm" for the sign-on. This is scheme, host, port for SCHEME_HTML.
   // Dialog based forms also contain the HTTP realm. Android based forms will
   // contain a string of the form "android://<hash of cert>@<package name>"
@@ -238,6 +256,9 @@ struct PasswordForm {
   // Once user selects this credential the flag is reseted.
   bool skip_zero_click;
 
+  // The layout as determined during parsing. Default value is LAYOUT_OTHER.
+  Layout layout;
+
   // Returns true if this match was found using public suffix matching.
   bool IsPublicSuffixMatch() const;
 
@@ -255,6 +276,7 @@ typedef std::map<base::string16, PasswordForm*> PasswordFormMap;
 typedef std::map<base::string16, const PasswordForm*> ConstPasswordFormMap;
 
 // For testing.
+std::ostream& operator<<(std::ostream& os, PasswordForm::Layout layout);
 std::ostream& operator<<(std::ostream& os,
                          const autofill::PasswordForm& form);