Re: [w3ctag/design-reviews] Incubation: Autofill Event (Issue #1197)

yoavweiss left a comment (w3ctag/design-reviews#1197)

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

We discussed your feedback at the [Autofill CG call on May 20](https://github.com/w3c-cg/autofill-cg/blob/main/meetings/2026-05-20.md). 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](https://github.com/w3c/webdriver-bidi/pull/706), which stalled in the WG for lack of implementer interest.
The relevant draft is currently in the same incubation repo ([`webdriver_integration.bs`](https://github.com/WICG/autofill-event/blob/main/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](https://github.com/WICG/autofill-event/blob/main/security_questionnaire.md), 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](https://github.com/WebKit/standards-positions/issues/431). 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.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1197#issuecomment-5510929402
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1197/5510929402@github.com>