Autofill event

concepts

1. Autofill Log

   A small form that listens for the autofill event on every field. When you let Chrome's password / address autofill fire, the log captures which fields were filled, in what order, and what the values were.

2. Refill flow

   Country lands first; the form mutates to ask for the right region-specific fields (US state, DE house number, BR neighbourhood), then calls event.refill() to ask the browser for a second pass.

3. Autofill vs Input Event

   Side-by-side comparison of the old heuristic — sniffing input events for inputType === "" — against the new explicit autofill event. Simulate both user typing and browser autofill to see false positives and the clean signal.

4. FormData Autofill Tester

   A multi-field checkout form with per-field autofill simulation buttons. Fires the autofill event via FormData construction and shows the event sequence, timing, and filled values — the canonical pattern for reacting to autofill in multi-step wizards.

5. Compatibility Lab

   Detects autofill event support via "autofill" in HTMLInputElement.prototype. Simulates autofill on a live form and compares the clean event signal against the legacy heuristics — input with no data, animationstart on :autofill. Provides a universal detection and fallback pattern.

why it exists

Forms that need to react to autofill — to update labels, validate cross-field constraints, fire analytics, or hydrate a wizard — have had no clean signal to hook into. Sites resorted to listening for input events with empty InputEvent.data (fragile), polling the :autofill CSS pseudo (worse), or sniffing the value across animationstart events triggered by autofill-specific keyframes (genuinely awful). The new autofill event is the missing primitive: a single explicit "the browser just filled this for the user" notification.

references

• ChromeStatus entry
• WHATWG discussion