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

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

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

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

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