Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Measuring the Impact of Autofill on Your Forms

DZone's Guide to

Measuring the Impact of Autofill on Your Forms

Paul Kinlan provides a call and case for browser standardization and measurement in terms of how they relate to autocomplete.

· Web Dev Zone
Free Resource

Learn how to build modern digital experience apps with Crafter CMS. Download this eBook now. Brought to you in partnership with Crafter Software

Autofill has a checkered history filled with what I believe is a mild case of FUD. Chrome, for the longest time, decided to ignore on forms and fields because we believed that autocomplete provides a huge amount of value for users especially in the context of mobile.

One problem is that it is incredibly hard to measure how impactful autocomplete is to your site. There aren’t really any events that happen when “autocomplete” occurs, so how do you measure what has happened?

I think there is a way, but it is not consistent across browsers.

Webkit and Blink Engines (Chrome, Samsung and Opera)

For a long time, WebKit had a pseudo class called -webkit-autofill that was applied to input elements. When the Chrome team forked WebKit and turned it into the blink engine, they also inherited this feature.

The -webkit-autofill pseudo class was designed to let you style and override the default “yellow” highlight when the browser executes the autofill. It is possible to use this pseudo selector to find all elements that have it applied using a simple document.querySelectorAll call as follows:

document.querySelectorAll('input:-webkit-autofill');

Likewise, you can listen to the input event on the input elements (or even on the document) and check to see if the event target would match the selector, as seen below:

[code: js]

document.addEventListener('input', function(e) {
var element = e.target.matches(':-webkit-autofill');
if(element) {
// Field auto-completed - Send an analytics event (or whatnot)
}
});

This works consistently across all WebKit and blink-based browsers. However, Mozilla hasn’t implemented it. There are numerous StackOverflow answers that suggest that :-moz-autofill works. But it doesn’t.

There was also a thread a while ago to standardize this, but no action has been taken.

If you are searching for autocomplete, you will also see an API called requestAutoComplete. It even has a handy onautocomplete event that is called when, well, the field is auto-filled. The problem is that this API is all but deprecated. I would love to see onautocomplete as an event that is triggered when the browser automatically fills the field. It is a very nice convenient function.

But the question still remains, how do you do this in Firefox and browsers that don’t support:-webkit-autofill?

Great question!

After some research that involved me crafting some simple tools for Firefox DevTools (I needed to be able to listen to all events happening on an element so I had to create a monitorEvents shim). Likewise, I had to also work out a way to find when an Element was created, so I ended up making a utility to resolve a promise when an element is added to the DOM. I think I have found a way to detect autocomplete in Firefox (and consistently across all other browsers).

What I found was that the oninput event will fire without any other events invoked, so there is no onkeypress, onkeyup, etc. I think there can be some false positives, but the signals look good.

var registerOnAutoComplete = function(elementSelector) {
return new Promise(function(resolve, reject) {
var element = document.querySelector(elementSelector);
var hasKeyInteraction = false;
element.addEventListener("input", function(e) {
if(hasKeyInteraction === false) {
resolve(e.target);
}
});
element.addEventListener("keydown", function(e) {
// If there is a keyboard interaction then we believe it is not autocomplete
hasKeyInteraction = true;
});
});
};

Usage is pretty simple for individual elements.

<script>
registerOnAutoComplete("input[]").then((element) => {
// Send some analytics data.
});
registerOnAutoComplete("input[]").then((element) => {
// Send some analytics data.
});
</script>
<form>
<input type="email" name="email">
<input type="password" name="password">
</form>

I think this is pretty interesting, as you can get data on which fields have been autofilled by the browser. However, you have to register for an event on them. This is why I really like the idea of a customonautocomplete event that as a developer I can listen for, or, if necessary, prevent.

I am going to do a couple more experiments because I would also like to register this once at the<form> level and I would like to get feedback to see if developers at large think this is as useful as I do.

My goal is to prove that autocomplete is a massive net-positive for users and businesses, but to do that we need to be able to measure it.

What Next?

I would really like this to be properly standardized, meaning:

  • Standardize and implement :autofill - CSS pseudo class so I can style but also select.

  • Rip out onautocomplete from the requestAutoComplete spec and trigger it when the browser actually autocomplete.

  • Allow the developer to preventDefault on onautocomplete if they have a better idea about what the data should be.

Crafter is a modern CMS platform for building modern websites and content-rich digital experiences. Download this eBook now. Brought to you in partnership with Crafter Software.

Topics:
autofill ,webkit ,web dev ,blink engines

Published at DZone with permission of Paul Kinlan, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}