We have regular complaints from web developers and users since bug 1025703 as there are valid use cases where autocomplete="new-password" doesn't cover a case where the user wouldn't want login autofill. An example includes where you need to enter credentials for Site B in a form on Site A. This is common for setting up integrations between services.

Other browsers were making/considering similar changes when we implemented bug 1025703 but bug commenters claim that Firefox's behaviour is different. We should make test login pages and then use it to make a table with the results of testing autocomplete=off's interaction on login autofill without user interaction (e.g. on page load) when there is one matching saved login:

• autocomplete=off only on <form>
• autocomplete=off on the username field, not on the password field
• autocomplete=off on the password field, not on the username field

Some documentation:

• https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion#The_autocomplete_attribute_and_login_fields (should maybe update this with our findings)
• https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9847360/
• https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164
• https://bugs.chromium.org/p/chromium/issues/detail?id=587466

Test login page with autocomplete=off on the <form> only.

I started putting data here: https://docs.google.com/spreadsheets/d/1XT8KCFGldYyFq7Bok2ndMPPBA0uCCFgWgzbXan6ywK4/edit?usp=sharing

The procedure is to

• use the browser under test to visit any of the attached test pages to enter a username & password and accept the prompt to save the login.
• Check about:preferences#privacy to ensure you have a single login only for bug1352544.bmoattachments.org
• re-visit each of the test pages in turn, noting which of the fields are autofilled (i.e. populated when the page loads with no further interaction from the user).

The doc is open for mozilla employees to edit; let me know if you need access or just send me results and I can enter them. Once baked, we can move the table to this bug or somewhere else permanent.

:MattN, I've got a start on the data I think you had in mind here in the doc in Comment 10. Can you confirm the test pages and the data coming out of them is what you had in mind and will be what we need to inform the decisions we need to make around this?

I think this is great, exactly what I wanted for a first pass :)

Some comments:

• I know that Chrome stores the id/name of the fields so I wondered if that influenced whether they fill but it doesn't seem to in my quick test.
• The Edge result somewhat surprises me as I know they did ignore autocomplete=off at one point (it's documented in Microsoft.com). I did hear from BMO commenters that Edge was honouring it again though.
• It seems like we are probably best sticking with our current behaviour (matching Chrome) on login pages like your test ones.

Can you also test with a pages like the following (don't bother testing with @autocomplete=off on only the <form> for now, just @autocomplete off on all password fields):

• 1pw: Only one field on the page inside a <form> which is <input type=password> (without an id/name) and without labels (no text outside the fields)
• 2pw: Same as the tests you already did but replace the username field with another password field and remove the @name attributes and labels.
• 3pw: Similar to the above but with only 3 password fields and no @name or labels.

I don't think you need to test on Android or with signon.autofillForms.autocompleteOff=false again btw. Without needing to test <form autocomplete="off"> this shouldn't be too bad of an ask (4 browsers x 3 new test pages = 12 tests) but let me know if you disagree.

Thanks!

I've got data now for the new forms and re-ran the results. Turns out I messed up with Edge the first time, it is autofilling some of those forms. I also added IE 11 to the mix.

Tabular results from testing login form autofill behavior for each of the form/autocomplete cases in Firefox Nightly, Chrome 72.0, MS Edge 42, Internet Explorer 11, Safari 12.02

In summary:

• Safari does no interactionless form autofill at all with any of the test cases. It only offers to fill fields when focus is placed in a field (autocomplete rather than autofill.)
• Firefox matches the behavior of each of the other major desktop browsers when the form has identifiable username and password fields, when autocomplete=off is used on any of the form, username or password fields.
• Firefox' behavior differs when the form has only one or more password fields, with or without autocomplete=off.
  • The single password field test is similar to a multi-page login process, or password entry to e.g. download a file or access a course. In case Chrome does not autofill the password, whereas Edge and IE11 do.
  • The two-passwords test is like a new password or password confirmation form. Firefox autfills the first password field, Chrome and Edge do not
  • The "2 password no @autocomplete" demonstrates this behavior is apparently not influenced by the use of autocomplete=off

This bug was created only to track gathering the behavior of auto-filling the forms/login forms with autocomplete=off on the main browsers, right? I am just making sure that there isn't something that needs verification about this bug. Thanks.

(In reply to Bodea Daniel [:danibodea] from comment #24)

This bug was created only to track gathering the behavior of auto-filling the forms/login forms with autocomplete=off on the main browsers, right? I am just making sure that there isn't something that needs verification about this bug. Thanks.

Right, no verification needed.