If you browse the web with Chrome — the excellent web browser from Google — the autocomplete feature probably saves you lots of time with passwords and repetitive text entry.
But if you’re a developer, or use any number of web services, very likely you find the autocomplete feature more troublesome than not.
What’s the big deal?
At this moment, you may be asking yourself: “So what? How does a change in the behaviour of this obscure HTML attribute affect me?”
To explain the problem, lets consider any website with a basic username and password login area. The first time you login, Chrome remembers the username and password to autocomplete the next time you visit the site.
So far, we are loving “autocomplete”.
Now consider any other activities you are carrying out on the site such as adding bank details to your accounting software, adding an account to your mail service provider, or in the case of Watchful users, adding backup secret keys or Words to Check to make your Joomla maintenance fast and easy.
In these and many other situations, any password fields will be automatically filled by Chrome using saved password from your intitial login. Of course, the password for your website should be different from that used for your other online activities.
As a result, your services will have the wrong credentials saved and thus fail to operate as desired.
It gets worse
In an effort to be more effective, Chrome also searches for the closest text input field preceeding the password field, and autocompletes it with the username saved from the intiial login to the website.
As with password autocompletion, it becomes difficult to enter the correct text into the credential fields.
In the past, website and webservice developers could solve this annoying problem by adding the autocomplete=”off” HTML attribute to the approipriate fields on their sites/applications. This would prevent Chrome from autocompleting the fields with inappropriate data.
However, ever since the Chrome developers decided to stop respecting this HTML attribute a great many applications and services have be affected.
The problem here at Watchful
As noted above, the Edit Site page here at Watchful is affected by the change in Chrome’s behaviour.
Specifically, the Chrome autocomplete feature affects two fields: the Akeeba Secret Word — a password field that allows us to manage Joomla backups — and the Word to Check field which is used to more accurately monitor uptime and is the closest text input preceding the Akeeba Secret Key.
If Chrome autocompletes these with your Watchful login credentials when you edit or add a site to your Watchful dashboard, both the uptime monitoring and remote backups will fail.
A simple solution
For this reason, today we changed the affected input fields to a “text” input. This exempts the fields from the autocomplete feature and solves the problem.