AutofillEvent() and AutofillEventInit

syntax

Quoted verbatim from the Autofill Event spec IDL (Draft CG Report, 25 September 2026):

constructor(DOMString type, optional AutofillEventInit eventInitDict = {});

dictionary AutofillEventInit : EventInit {
  sequence<AutofillValueEntry> autofillValues = [];
  boolean allowRefill = true;
};

typedef sequence<any> AutofillValueEntry;
// AutofillValueEntry is a tuple of [HTMLElement, DOMString]

JavaScript call shape: new AutofillEvent(type) or new AutofillEvent(type, eventInitDict).

parameters

return value

In the WICG draft, construction would return a new AutofillEvent whose autofillValues reflects the dictionary entries. In flagged Chrome 154 it instead throws TypeError: Illegal constructor. Draft-only unknown: the spec text (read 2026-10-04) defines no bespoke constructor steps and does not state what the refill attribute returns on a synthetically constructed event — refill is described only as populated during the user agent’s own firing algorithm (§3.1). Treat refill on synthetic events as unspecified in the 25 September 2026 draft.

exceptions

The WICG draft defines no constructor-specific exceptions (verified against the full draft, 2026-10-04), but the observed flagged Chrome 154 interface has no web-exposed constructor and throws TypeError: Illegal constructor before processing this dictionary. For a browser that implements the draft constructor, only standard Web IDL argument conversions apply: a TypeError for an eventInitDict value that cannot convert to AutofillEventInit (e.g. autofillValues set to a non-iterable). Per standard dictionary conversion, unknown members are ignored.

context and exposure

[Exposed=Window] only — no Worker exposure in the WICG draft or pinned Chromium IDL. The draft intends third-party autofill providers (extensions, password managers) as callers (spec §6.1). AutofillEventInit is a draft dictionary with no global-object presence. typeof AutofillEvent === "function" detects the interface, not a usable constructor: it returned true in flagged Chrome 154 even though new AutofillEvent(...) failed.

lifecycle

In a browser that implements the WICG draft constructor, the dictionary is read once during construction, standard Web IDL behavior; mutating it afterwards does not change the event. allowRefill: false reproduces the browser’s own retry dispatch, where §4.1 fires with allowRefill false so a second refill is refused with "InvalidStateError" (§4.2). A synthetic event would participate in normal DOM dispatch (the WICG draft says its browser-generated event bubbles from the Document; pinned Chromium implements a non-bubbling browser event and no synthetic constructor). The draft does not give synthetic dispatch any of the firing algorithm’s side effects — constructing and dispatching an AutofillEvent does not itself fill any fields.

examples

WICG draft illustration only — not runnable in the observed flagged Chrome 154: a third-party provider signalling its own fill with the proposed event structure, gendn-derived from the draft IDL and §6.1. No Chromium synthetic autofill/refill flow has been verified:

const email = document.querySelector('input[autocomplete="email"]');
const name  = document.querySelector('input[autocomplete="name"]');

const event = new AutofillEvent('autofill', {
  bubbles: true,                     // match the UA dispatch (spec section 4.1)
  autofillValues: [
    [name,  'Ada Lovelace'],
    [email, 'ada@example.com'],
  ],
  allowRefill: false,                // this provider does not support refills
});

document.dispatchEvent(event);       // the UA fires at the Document; do the same
// Note: dispatching the event does NOT fill the fields — the provider
// still writes the values itself. The event keeps page-side listeners
// working identically for UA and third-party fills.

browser compatibility

Interim table. BCD api/AutofillEvent.json records the interface and its two members but no separate constructor or AutofillEventInit sub-feature (checked 2026-10-08). Constructor support must not be inferred from the interface entry; flagged Chrome 154 provides a counterexample.

security and privacy

Synthetic construction is the spec’s sanctioned hook for third-party autofill providers (§6.1): because every source dispatches an event “with the same structure”, one listener handles browser autofill and third-party fills alike. The sources remain distinguishable at the trust level, though — an event a provider dispatches from script via dispatchEvent() has isTrusted === false, unlike a user-agent-generated autofill event, and isTrusted says nothing about which provider dispatched it. The constructor exposes no user data by itself; it only carries values the caller already holds. The consent considerations of §6 (fire only after explicit user consent to autofill) are obligations on the dispatching provider.

see also

• Autofill event — overview
• The "full-address" autocomplete token
• WebDriver BiDi autofill.trigger
• Autofill Event specification (WICG)
• chromestatus — Autofill event (5137581018841088)