Why Chrome autofill breaks on SPAs and dynamic web apps

By QuickForm Teamยท
QuickForm in action: autofilling dynamic web apps in one click

React, Angular, and Vue are the dominant SPA frameworks according to the State of JS 2024 survey (State of JS, "State of JavaScript 2024: Front-end Frameworks"), and together they power the vast majority of single-page applications on the web today. What they share, beyond component-based rendering, is a structural conflict with Chrome's autofill system. Chrome autofill was built for traditional page loads, and SPAs replace page loads with client-side route transitions. The signals Chrome depends on to find and fill forms simply never arrive.

Key Takeaways

  • Chrome writes a field's .value directly; SPA frameworks only update state from dispatched events, so the direct write is invisible to the framework's reactivity system.
  • React, Angular, and Vue are the dominant SPA frameworks per State of JS 2024, meaning this affects most of the SPA-powered web.
  • SPA fields often mount after Chrome's initial autofill scan, so even the first page load can miss forms inside lazy-loaded components.
  • The autocomplete attribute helps with field identification but does not change which event Chrome fires after filling.
  • Across 93 million tracked sessions, the average form completes just 51.7% of the time (Zuko, "25 Conversion Rate Statistics You Need"). Broken autofill is a direct driver of that gap.

Why does Chrome autofill fail on SPAs?

Chrome's autofill scanner runs on DOMContentLoaded and load events, the signals a traditional page navigation always fires. A route transition in a SPA does not unload the document: the URL changes via the History API, a framework swaps out the DOM, and the form appears, but neither event fires. Chrome's scanner never wakes up for that form. The user has a saved address stored, the form is right there, but the browser and the app are not speaking the same protocol.

The problem compounds for dynamically rendered forms. SPA fields often mount after Chrome's initial autofill scan, because they live inside lazy-loaded components or appear after an API response. By the time the fields are in the DOM, Chrome's scan window has passed. Unlike framework-specific issues covered in the React autofill post, this problem is not tied to a single event type: it is a navigation architecture mismatch that affects every SPA framework.

How do you fix SPA autofill in code?

The code-level fix has two parts: trigger Chrome's scanner after navigation completes, then use the native setter to replay values with the events each framework actually listens for:

const input = document.querySelector("#email")
// SPA frameworks override the value setter, so reach the native one:
const nativeSetter = Object.getOwnPropertyDescriptor(
  window.HTMLInputElement.prototype, "value").set
nativeSetter.call(input, "[email protected]")
input.dispatchEvent(new Event("input", { bubbles: true }))
input.dispatchEvent(new Event("change", { bubbles: true })) // change added for safety across frameworks

SPA fields often mount after Chrome's initial autofill scan, so time this code to run after the router has finished rendering the new route, not on page load. The input event covers React and Vue's v-model; the change event covers Angular's NgModel and generic form libraries. Skip the native setter and the framework's overridden setter absorbs the write without triggering reactivity.

Does the autocomplete attribute fix it?

Not on its own. Adding autocomplete="email" is still worth doing: W3C's WCAG 2.2 criterion 1.3.5 Identify Input Purpose recommends it so assistive tech and password managers can identify the field's purpose, which helps users with cognitive and motor needs (W3C, "Understanding SC 1.3.5: Identify Input Purpose (WCAG 2.2)"). But the attribute only informs Chrome what a field is for. It does not change which event Chrome dispatches after filling, and it does nothing about the missing scanner trigger during client-side navigation. Use it alongside the fix, not instead of it.

What does broken SPA autofill cost your users?

Friction at the form is where conversions die. Across 93 million tracked sessions, Zuko found the average online form completes just 51.7% of the time, and form length is the single reason cited by 27% of people who quit (Zuko, "25 Conversion Rate Statistics You Need", 2025). SPA architectures are most common for checkout and onboarding flows, precisely the multi-step funnels where autofill usage is highest. When autofill works on the first step but fails on every subsequent step reached via client navigation, users face manual re-entry on the fields they most expected the browser to handle, which pushes completion rates below that already-low baseline.

The no-code fix: QuickForm Record Mode

Not everyone owns the page, and patching the router in every SPA is not always practical. A dedicated autofill extension for SPAs does the same job as the snippet above without touching application code. QuickForm's Record Mode captures your real keystrokes once, then replays them through the native-setter-plus-event path each framework expects. It fills on demand when you click the extension icon, with no dependency on page-load events or router timing.

Fill SPA forms in one click, free

No account required. Works in 60 seconds.

Add to Chrome, it's free

50,000+ users ยท 4.2 stars

Setting it up takes about a minute:

  1. Install QuickForm from the Chrome Web Store (free, no account needed)
  2. Open the SPA form you want to autofill
  3. Click the QuickForm icon, then enable Record Mode
  4. Fill the form once, normally. QuickForm captures every field
  5. Save the profile and give it a name
  6. Next time, click the profile and the whole form fills in one click, regardless of how the route was loaded

Fill SPA forms in one click, free

No account required. Works in 60 seconds.

Add to Chrome, it's free

50,000+ users ยท 4.2 stars

Frequently asked questions

Why does Chrome autofill not work in SPAs?
Chrome's autofill scanner runs on DOMContentLoaded and load events. SPA client-side navigation changes the URL via the History API without firing either event, so Chrome's scanner never runs for forms loaded during route transitions.
Why does autofill work on the first SPA page load but fail on later routes?
The initial page load fires real DOMContentLoaded and load events, so Chrome's scanner runs. Every subsequent route is a client-side transition with no page load, so the scanner never fires again during that session.
Does adding autocomplete attributes fix SPA autofill?
It helps Chrome identify what to fill per WCAG 1.3.5, but it does not solve the missing scanner trigger during client-side navigation. The attribute alone does not resolve the structural SPA mismatch.
Do I need to write code to use QuickForm?
No. Record Mode captures your keystrokes as you fill the form once, then replays them with the events each framework expects, timed after the route finishes rendering. No router patches, no native-setter code, no config files.

Sources

  • State of JS. State of JavaScript 2024: Front-end Frameworks. 2024.stateofjs.com (retrieved 2026-06-09)
  • W3C. Understanding SC 1.3.5: Identify Input Purpose (WCAG 2.2). w3.org (retrieved 2026-06-09)
  • Zuko. 25 Conversion Rate Statistics You Need. zuko.io (retrieved 2026-06-09)