#3470 - Change our approach to autofill

Identifier #3470
Issue type Feature request or suggestion
Title Change our approach to autofill
Status Completed
Tags

Type: Standards compliance (custom)

Handling member Salman
Addon core
Description The 'autocomplete' attribute is now very broken due to a cold war between browser UX people and security people - security people would recommend disabling it, and UX people want the browser users to control that. So the browser UX people stopped reliably respecting webmaster preferences.

Additionally, autocomplete="off" is breaking form auto-refill upon clicking back. This shouldn't happen IMO, as that is separate from autofill, but there's no way to distinguish these scenarios as a webmaster.

As a result, we need to play nice with how browser's will implement autofill, rather than trying to tell the browser when it can/cannot use it.


Never use autocomplete="off" (remove 'autocomplete' from webstandards checker grammar given now Chrome may completely ignore it, and other browsers ignore it for password fields)

We will standardise around these autocompletable fields: username, password, email, firstname, lastname, name, birthday, address1, city, state, postalcode, country, phone, email. These are the field names most reliably supported (we will only focus on login and address autofill, not credit card autofill).

When editing anything with any of the autocompletable fields, prefix the field name with 'edit_'

Use the standardised autocompletable field names to make best use of browser autofill, these particular cases are identified:
poster_name_if_guest -> name
email_address -> email
recommender_email_address -> email
date_of_birth -> birthday
dob -> birthday
street_address --> address1
post_code -> postalcode

Block creating fields with these names in dev-mode (as they will not reliably work with autofill):
email_address
date_of_birth
dob
street_address
post_code

Avoid any field named 'name' unless it really is a human name; consider 'title'

Change webstandards checker to allow use of the WHATWG HTML5 autocomplete tagging API (https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill)

Extend the form_templates API to take explicit metadata for many of the field types

Automatically provide metadata for the WHATWG HTML5 autocomplete tagging API based on our standardised autocompletable field names, in the form_templates API (give an error if a positive detection mismatches with an explicit value given)

Also provide metadata for any edit_* fields, with a value of 'autocomplete-disabled'

Add a CPF field option to provide autocomplete metadata, and do this for all the bundled CPFs; however this will only be passed through on join/add forms

Change these instructions into a coding standard
Steps to reproduce

Additional information By removing autocomplete="off" we get working repopulation on back working.

By positively respecting standardised field names we get the positive benefits of autofill, while avoiding unintentional autofill.

By avoiding standardised field names we avoid false positives.

By mapping standardised field names to the new WHATWG API we are futureproof.

By using 'edit_' prefixing, and mapping to a 'autocomplete-disabled' value we avoid autofill happening on edit screens.

By using the WHATWG API on CPFs we allow autofill of CPFs.
Funded? No
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".

Rating

Unrated