Testing autofill in Chrome sounds simple until you actually try it on localhost. Chrome treats local and non-secure origins differently from production, password managers behave inconsistently, and the events Chrome fires when it autofills a form are not the same events a tester fires when typing by hand. Most "autofill works" QA passes are not actually testing autofill at all.
This guide walks through how to test Chrome autofill correctly on localhost, staging, and production-like environments — and how to catch the bugs that only appear when values arrive the way Chrome actually delivers them.
Why testing autofill is harder than it looks
When Chrome autofills a form, it does several things at once:
- it sets the field's
valueproperty directly - it dispatches an
inputevent and achangeevent - it does not dispatch
keydown,keypress, orkeyupevents - it may apply a yellow background that is only visible in certain Chrome versions
- on some inputs it waits until the user interacts with the page before filling
That last point is the one that breaks most local tests. Chrome will sometimes refuse to autofill until the user has clicked or pressed a key on the page first. If your QA tester never interacts with the page before checking, autofill silently does nothing and the test "passes".
Step 1: Get Chrome to actually autofill on localhost
Chrome's autofill heuristics are conservative on http://localhost and unfamiliar staging domains. To make autofill behave consistently:
- Use
https://in staging whenever possible. Chrome trusts secure origins more. - Make sure your
<input>elements have correctautocompleteattributes (given-name,family-name,email,tel,street-address,postal-code, etc.). Chrome's documented autofill behavior depends on these. - Add a
nameattribute. Chrome uses bothnameandautocompleteto decide what to fill. - Avoid wrapping inputs in custom web components without forwarding the autofill events — Chrome may detect the field but the event will never reach your framework state.
- Click somewhere on the page before triggering autofill. Chrome will not always fill on a fresh, untouched tab.
If you skip these, you are not testing autofill. You are testing a form that Chrome silently refused to autofill.
Step 2: Verify Chrome actually filled the form
Chrome's input and change events are the only signal you get. To confirm a field was actually autofilled (not just visually populated by a previous test run):
- Open DevTools → Elements → select the input.
- In the Console, run
$0.valueand compare to what you see on screen. - Then run
getEventListeners($0)and check that your framework's listeners are bound toinputandchange, not justkeyup. - Open the React/Vue/Angular devtools panel and confirm the component state matches
$0.value. If they disagree, your form has an autofill bug.
This is the step almost every QA pass skips, and it is exactly where the bugs hide.
Step 3: Test the validation path
Most autofill bugs are not "the field did not fill". They are "the field filled, but validation never re-ran". To catch these:
- Autofill the form.
- Without clicking or tabbing, check whether the submit button is enabled.
- Check whether any required-field error messages cleared.
- If the submit button is still disabled or errors are still showing, your validation is listening to the wrong event.
Common culprits:
- validation bound to
keyupinstead ofinput/change - validators that read from a stale internal state object
- form libraries (e.g. older React Hook Form configs) that need an explicit
setValuecall - masked-input libraries that strip the value when it arrives instantly
Step 4: Test on staging the way users will use it
Localhost and staging behave differently from production. To get a realistic signal:
- Use a staging URL that is HTTPS and reasonably close to your production domain.
- Test in a fresh Chrome profile with no saved form data — then in your real profile with saved data — then in Incognito with autofill disabled. All three matter.
- Test with at least one third-party password manager enabled (1Password, Bitwarden). Their autofill paths are different from Chrome's built-in.
- Test the same form on a mobile Chrome device. Mobile autofill is more aggressive and more likely to expose bugs.
Step 5: Use a form filler extension to simulate browser autofill at scale
Manual Chrome autofill is fine for spot checks, but it does not scale to a full QA pass. A form filler extension that fires the same events Chrome does — input, change, and blur, in the right order — lets you run the same test on every form, every release, in seconds.
That is exactly what MockFill is built for. It detects every field on the page, fills realistic values, fires native browser events, and works on localhost and staging without any setup or configuration.
Common Chrome autofill bugs this workflow catches
After running this process on enough forms, you will see the same handful of bugs over and over:
- React forms where
valueupdates butonChangenever fires - Material UI / Ant Design fields where the floating label does not reset
- Address forms where the country dropdown fills but state and city do not
- Card-number inputs that drop digits when masking is applied to the autofilled value
- Multi-step forms that lose autofilled values after navigating between steps
- Forms where the submit button stays disabled because validation is bound to keyboard events only
Each of these has shipped to production at companies you have heard of. They are all preventable.
Install MockFill from the Chrome Web Store
If you want to run this workflow without doing the manual DevTools dance every time:
- Install MockFill on Chrome
- Use it on localhost and staging the same way Chrome's own autofill would, but with realistic data and consistent results.

