Thanks for the proposal. We have a few questions and comments for your consideration.

First, we think you should standardize UA behavior when forms change as a result of autofill, particularly where dynamically rendered or progressively disclosed forms may not align with the user agent’s original understanding of the form structure, and then see whether you actually still need a new developer-visible feature. Interoperable test coverage here seems important.

Second, there are privacy considerations that would benefit from further development. In particular:

• whether sites could use this feature to infer information about stored user profile data more than is currently possible,
• whether hidden or dynamically inserted fields create new data collection opportunities,
• whether users understand what data is shared when autofill is invoked. (This will likely vary per browser UI, but you might demonstrate some possibilities that are likely to explain what data is exposed by dynamic autofill.)

Third, we have questions as to how this would interact with form validation. This behavior is already not interoperable across different browsers. For example, on Chromium, autofill does not trigger validation updates, so you can autofill a form with invalid data and then submit it. In Safari and Firefox, it does trigger validation. The expected behavior should be more fully specified.

We are also concerned about potential user experience risks, including:

• pages responding to the autofill event in ways users may find surprising or disruptive,
• pages clearing, rejecting, or interfering with autofilled values,
• pages gaining signals about whether data was autofilled versus manually entered, where that distinction may not be necessary for the user’s benefit.

We also noticed some areas that appear underdeveloped in the current explainer:

• accessibility considerations, particularly for dynamic form changes and event sequencing,
• clearer handling and consent expectations for full-address requests.

One omission from the draft: the spec and explainer currently contradict each other:

Spec: bubbles: true; README: "The event does not bubble"
Spec: autofillValues; README: values
README: checkbox/radio values are boolean; Spec IDL: typedef sequence<any> ([HTMLElement, DOMString])

It would be helpful to clarify which invariants you want to require for the user agent when it comes to user intent, data disclosure, and the final form state after page-script interaction. Also, consider gathering evidence as you proceed through origin trials to determine whether this helps the websites and any outcomes of a user study measuring what people understand from the adopted UIs. We suggest you also bring these ideas to WHATWG’s HTML Work Stream (instead of doing new work/API) and work on this together with the HTML folks. Another avenue where you might gather input is Interop 2027

Following up. @yoavweiss , any further thoughts?

Thanks for the thorough review, and apologies for the delay here..

We discussed your feedback at the Autofill CG call on May 20. Below is my attempt at summarizing that discussion:

1. Standardizing UA behavior on dynamic forms first

From talking to implementers, I'm not sure that there's appetite for standardization of the specific heuristics that user agents and autofill providers use. At the same time, I strongly agree that this area requires more test coverage, and beyond that, testability. Currently, there is no interoperable way to trigger autofill from an automated test, so WPT coverage for autofill is essentially impossible today. I previously took a stab at this in w3c/webdriver-bidi#706, which stalled in the WG for lack of implementer interest. The relevant draft is currently in the same incubation repo (webdriver_integration.bs). It's likely that any attempt to ship this API will also require shipping such testing facilities.

At the same time, it's unclear how standardizing UA behavior would absolve us from needing "a new developer-visible feature." Currently UAs don't have all the information they need to perform autofill at the time they are performing it, given that the address format and its fields depend on the country, and the country is not necessarily known before autofill triggered. Some UAs solve this with re-triggering autofill later if/when the form changes, but that's an inherently racy solution (and would be tricky to specify) when it doesn't keep the developer in the loop.

The industry's answer to that is hidden "honeypot" fields, which are hacky, hard to maintain and are user hostile. I'd love to see a future where those are no longer needed.

2. Privacy

The event does not expose any new information beyond what's currently exposed in the fields themselves once autofill ran. Beyond that, it's obsoleting the need for hidden fields (at least in supporting browsers), resulting in such browsers being able to e.g. stop filling hidden fields over time.

This is covered in the S&P questionnaire, but we'll make sure this is well covered in the spec's Privacy section.

3. Form validation

Thanks for pointing this out. It's unclear that Chromium's behavior is not a bug. IIRC, @stephenmcgruer signed up to look into this. At the same time, as part of specifying the feature (and introducing autofill test infrastructure), we should probably also specify and test that validation & autofill work according to our expectations.

4. User experience risks

This is the same concern WebKit raised. It took up most of the CG call, and we didn't really reach consensus on it.

My take is that I agree that pages that clear, reject, or fight autofilled values are harming users, and the platform shouldn't make that materially cheaper. But I don't think this event materially lowers the cost of that harm.

Adversarial sites motivated to detect autofill already can use the following for that purpose:

• the :autofill pseudo-class
• event-sequencing and timing signatures
• trusted-vs-untrusted event heuristics
• multi-field simultaneous-change heuristics.

User agents could e.g. put such abusive sites on a quirks list that would mean that event doesn't fire for them. Or they could enable the event for e.g. address forms but not other types of forms.

But not shipping the event won't materially change the abuse calculus while at the same time leave well-meaning site worse off, and having to resort to hacks to get their autofill working.

The flip side of this is that there's a good chance that a lot of what's perceived as abuse are actually site bugs, that are a function of today's autofill being overly complex. Shipping the API will actively help these cases.

5. Accessibility

We'd appreciate specific concerns you may have on this. I'm personally not sure about the difference between forms changing dynamically as a result of the "autofill" event, and ones that do so as a result of a "change" event.

6. full-address

That's a part that's not yet implemented (it's not really needed in Chromium, which AFAIU assumes that user consent for an address autofill covers all of it already). It's something that other implementers and autofill providers told us they may need, as they have a different model.

7. Other

One omission from the draft: the spec and explainer currently contradict each other:

Spec: bubbles: true; README: "The event does not bubble"
Spec: autofillValues; README: values
README: checkbox/radio values are boolean; Spec IDL: typedef sequence<any> ([HTMLElement, DOMString])

Thanks for catching that!! We'll fix it :)

It would be helpful to clarify which invariants you want to require for the user agent when it comes to user intent, data disclosure, and the final form state after page-script interaction.

I'm not sure I understand this one. Autofill is an existing browser feature, and this feature integrates with it. This feature doesn't not redefine the various browsers' implementation of autofill.

Also, consider gathering evidence as you proceed through origin trials to determine whether this helps the websites and any outcomes of a user study measuring what people understand from the adopted UIs.

As the API doesn't change the UI and is not user facing, I don't think there's any need for a user study. The Origin Trial will enable us to measure the benefits of this approach, compared to the honeypot fields approach.

We suggest you also bring these ideas to WHATWG’s HTML Work Stream

Makes sense!

Another avenue where you might gather input is Interop 2027

It could've been interesting on the testing front, but as I mentioned above, there wasn't enough implementer interest in the relevant WG.