View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003470 | Composr | core | public | 2017-12-31 22:13 | 2019-06-22 00:19 |
| Reporter | Chris Graham | Assigned To | Salman | ||
| Severity | Feature-request | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | |||||
| Fixed in Version | |||||
| Summary | 0003470: Change our approach to autofill | ||||
| 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 | ||||
| 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. | ||||
| Tags | Type: Standards compliance | ||||
| Time estimation (hours) | 6 | ||||
| Sponsorship open | |||||
|
|
Chris, I just renamed input[name="login_username"] to input[name="username"] as part of our standardization. This sadly kills easy grep-ability for the username field. If you intentionally omitted this case, we can simply revert this commit: https://github.com/ocproducts/composr/commit/9a915682e88f7ba8bfac84dd85e6569d1d50bd88 |
|
|
Ok, that may be problematic, but with some work can be ok. The handle_logins function reads it in to support a login *on any screen*. However, if the join screen is sending it, we obviously won't want that to trigger it. So I suggest we have something like a parameter named _active_login, and only if that's set to 1 it'll look for 'username'. Additionally we need to make sure IDs are still distinct. Login block may show at same time as join page or login page, but IDs are globally unique within a page. |
|
|
All done in the 'v11_redesign' branch. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2017-12-31 22:13 | Chris Graham | New Issue | |
| 2017-12-31 22:14 | Chris Graham | Tag Attached: Type: Standards compliance | |
| 2017-12-31 22:19 | Chris Graham | Description Updated | View Revisions |
| 2017-12-31 22:19 | Chris Graham | Additional Information Updated | View Revisions |
| 2019-02-22 16:36 | Chris Graham | Assigned To | => Salman |
| 2019-02-22 16:36 | Chris Graham | Status | non-assigned => assigned |
| 2019-02-25 01:47 | Salman | Note Added: 0005925 | |
| 2019-02-25 05:20 | Chris Graham | Note Added: 0005926 | |
| 2019-06-22 00:19 | Salman | Status | assigned => resolved |
| 2019-06-22 00:19 | Salman | Resolution | open => fixed |
| 2019-06-22 00:19 | Salman | Note Added: 0005978 |
