Web client forms need autocomplete and autocapitalize attributes

[Jason Boyer]

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)]

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.

[Remington Steed (rjs7)]

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)]

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?)

[Josh Stompro (u-launchpad-stompro-org)]

It looks like Firefox will support the autocomplete="new-password" soon, which will be nice.

https://bugzilla.mozilla.org/show_bug.cgi?id=1119063

Josh

[Terran McCanna (tmccanna)]

Received a merge conflict when trying to apply to current master.

[Michele Morgan (mmorgan)]

Removing pullrequest as this patch needs a rebase.

[Michele Morgan (mmorgan)]

In response to comments on IRC about this, +1 to splitting this up into separate bugs that address smaller chunks of code. For example, staff client acq, staff client circ, tpac, etc.

This would make it easier to test and keep current.

Link to IRC comments:

http://irc.evergreen-ils.org/evergreen/2021-01-07#i_470384