Web client forms need autocomplete and autocapitalize attributes

Bug #1778063 reported by Jason Boyer on 2018-06-21
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Medium
Unassigned

Bug Description

Now that we're using a web app in whatever browser the user chooses there are some things we can do to make the experience of using it better for those users. The staff and opac login forms can be improved by adding autocomplete hints to assist password managers and disabling autocapitalize will help with mobile entry. Both attributes should be disabled in all staff client forms because you don't want your client "helpfully" suggesting barcodes and searches from last week. The good news is that if applied to the <form> element then all input elements within it inherit them.

Jason Boyer (jboyer) on 2018-06-21
Changed in evergreen:
importance: Undecided → Wishlist
Jason Boyer (jboyer) on 2018-11-06
Changed in evergreen:
importance: Wishlist → Medium
Jason Boyer (jboyer) wrote :

I've bumped the importance because I've been getting reports of libraries running into issues with the wrong items being checked in at various locations, and local staff have narrowed it down to autocomplete interference. Here's a branch that does a couple things; in the staff client portions autocomplete is largely disabled everywhere because there's no benefit to a browser trying to guess what you want to do. Where it makes sense in the public facing parts of the opac autocomplete options are specified to make things more reliable and simpler for password managers and browser personal information features to use appropriately.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/jboyer/lp1778063_autocomplete working/user/jboyer/lp1778063_autocomplete

Testing can be annoying because Chrome doesn't necessarily save every value every time. With this patch installed it should remember next to nothing for staff. The staff and opac login pages are also enhanced for mobile to stop auto-capitalizing the username on the login form.

tags: added: pullrequest
Remington Steed (rjs7) on 2018-12-04
Changed in evergreen:
status: New → Confirmed
milestone: none → 3.2.3
tags: added: usability
Remington Steed (rjs7) wrote :

Jason, just looking through your branch, the changes look sensible (and comprehensive!). Just two exceptions that confused me a little, in this file:

Open-ILS/src/templates/staff/circ/patron/t_edit.tt2

One occurrence of autocomplete="nerp".
One occurrence of autocomplete="nah".

Are those on purpose? They didn't seem to fit the pattern.

Jason Boyer (jboyer) wrote :

Those are intentional because browsers usually decide that they know best when it comes to usernames and passwords and will ignore the usual autocomplete="off" attribute. When presented with an autocomplete type that they don't know about though, they stop trying to second guess us and leave the fields alone.

Though looking at https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion it seems that Firefox specifically thwarts this method by returning to the default handling for those fields. :( I was trying to be sure that the browser never tries to suggests a saved set of staff credentials for a new user (or asks to replace staff credentials with a newly created one!) Looks like that may only be true for Chrome and Safari. (For now?)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers