Not sure if this is a feature request or if there’s an existing solution, or maybe just a discussion that could lead to one of those.
The issue is that browsers (Safari in particular) have a really hard-to-bypass habit of invoking autofill/autocomplete in text fields. This is super useful in most “consumer” -facing web forms. You order something online, join a list, etc… having these fields easily filled with your info or even others in your contacts book is great.
But it becomes a problem in situations where you don’t want to do this. Mostly, non-consumer type forms. And it’s a huge nuisance when you’re working with non-human entities. $this->Form->control('name')for an article entity, for example.
Worst of all, it becomes a total barrier to usability if you are using any kind of live-search feature on a page. The browser’s list of autofill options gets overlain on top of the live-search results, making it hard or impossible to read some of those records, and even steals keyboard focus so the user cannot keyboard select a returned option.
Having read a very little bit on the internet about this, it sounds like the issue is that the browsers look at the inputs id, name, and even label to decide whether autocomplete/autofill should be triggered. There is a long list of trigger words, of which “name” is one.
CakePHP is designed so that if you use “name” as a field name, it is automatically assumed to be the primary display value for a record. This is extremely helpful across a CakePHP app. But, this browser autofill/autocomplete really detracts from it.
I was thinking the solution to this would be to automatically and transparently rename every such field with an alias when using form fields. So “Article.name” becomes “Article.Qfvgr” in a form and then its reassigned back to “Article.name” after submission. Also, the field label would have to be mangled a bit (swapping a straight-up character with its unicode number appears to be enough to obfuscate a label from the browser’s “ai”). However. this presents a problem for screen readers… an alternative workaround perhaps would be to not assign those labels to their corresponding fields and hope proximity is good enough?.
Of course, such functionality would have to be “opt-in” on a model-by-model basis.
I’m thinking maybe a behavior might get me there.
Anyone else run into this and figure out a good way to zap it?