Over a million developers have joined DZone.

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

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

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.

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.

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 best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

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

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

{{ parent.tldr }}

{{ parent.urlSource.name }}