Intent to Prototype: Autofill event

[Yoav Weiss (@Shopify)]

Contact emails

yoav...@chromium.org, schw...@google.com

Explainer

https://github.com/WICG/autofill-event?tab=readme-ov-file#autofill-event

Specification

https://wicg.github.io/autofill-event

Summary

Autofill is a key feature of the web that reduces friction for millions of users everyday. But getting autofill to work reliably with dynamic forms across multiple implementations requires jumping through many hoops. This feature adds an "autofill" event that would allow developers to modify their forms to fit the autofilled data and let the browser know when they have done so.

Blink component

Blink

Web Feature ID

Missing feature

Motivation

Autofill today relies on static forms, but address forms are dynamic, almost by definition. Addresses around the world have different fields and requirements, and developers have to reconcile that dynamic nature with autofill's static nature. Some browser heuristics are simplifying that task in some implementations, but dealing with that implementation-specific complexity requires jumping through a bunch of hoops. This feature will enable developers to be notified of autofill-filled values, modify the form to match the filled data and let the browser know when that modification happened, enabling the browser to refill the data in the adapted form.

Initial public proposal

https://github.com/WICG/proposals/issues/162

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/issues/466333215

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5137581018841088?gate=5148847959572480

This intent message was generated by Chrome Platform Status.

[Chris Thompson]

Hi Yoav --

Chrome web platform security folks took a quick look at this -- we think there aren't any concerns but I think the spec could be clarified a bit to make it more obviously the case :-)

Section 6 flags that UAs SHOULD only expose the data after explicit user confirmation. We think this is also important irrespective of timing attacks. It also wasn't immediately clear to us that the data being passed is limited to the specific autofill fields/type initially requested (and thus confirmed by the user) and this cannot be changed by the page handling the autofill event -- i.e., that all that can happen is a refill for the same data the user already consented to share. Maybe this is just under-specified and UA-dependent? I think it would still be good to at least discuss in the Security/Privacy considerations section, even if it's non-normative. Additionally, given that requirement, the new "full-address" field name may have UX challenges to ensure that the user understands the full scope of what is being shared.

Cheers,

Chris

[Yoav Weiss (@Shopify)]

Hey Chris!

On Mon, Jan 26, 2026 at 9:10 PM Chris Thompson <cth...@google.com> wrote:

Hi Yoav --

Chrome web platform security folks took a quick look at this -- we think there aren't any concerns but I think the spec could be clarified a bit to make it more obviously the case :-)

Section 6 flags that UAs SHOULD only expose the data after explicit user confirmation. We think this is also important irrespective of timing attacks.

Yeah, the "timing attack" title is not appropriate. I'll revamp.
 

It also wasn't immediately clear to us that the data being passed is limited to the specific autofill fields/type initially requested (and thus confirmed by the user) and this cannot be changed by the page handling the autofill event -- i.e., that all that can happen is a refill for the same data the user already consented to share. Maybe this is just under-specified and UA-dependent?

It's indeed not specified (as it's not specified today), but at the same time, the spec does define the "full-address" autocomplete value that enables the UA to know ahead of time that it needs to get user consent for the entire address information, not just the fields currently present in the form.

We heard feedback from some UAs that this would be required for them, while others felt that getting user consent of the specific parts of the address implies consent for the more generic parts.

The attribute will enable each UA to apply the policy it deems fit.

I think it would still be good to at least discuss in the Security/Privacy considerations section, even if it's non-normative.

Sure!

 

Additionally, given that requirement, the new "full-address" field name may have UX challenges to ensure that the user understands the full scope of what is being shared.

Potentially, but I imagined it being equivalent to pretending that all the fields that are relevant to the user's address are already present in the form.