An autofill checker answers the one question that one-click form fillers usually skip: did the form actually accept the data, or does it just look filled? The visible UI and the form's real internal state disagree more often than most QA teams realize, and that disagreement is where the worst form bugs live.
This is the checklist a QA engineer should run after every autofill pass — the practical version, not the abstract one — so the bugs that survive autofill do not survive into production.
The gap between "filled" and "accepted"
When you autofill a form, three different things have to be true for the form to actually be "filled":
- The DOM
valueof every input is set. - Every framework's internal state (React, Vue, Angular, Svelte) matches the DOM.
- Every validator has re-run and updated its result.
A naive form filler only does #1. The other two are silent. That is why you can autofill a form, see all the values on screen, click submit, and get "email is required" — the email is visually there, but the form's state object never knew about it.
An autofill checker exists to verify all three.
The autofill checker checklist
After a one-click fill, run this checklist before trusting the result.
1. Every visible field has a value
Sounds obvious. But check the fields that look filled, not just the ones that are obviously empty. Floating labels and placeholder styles can make an empty field look populated.
2. Every required field is internally filled
Open the React/Vue/Angular devtools panel. Look at the form's state object. Every field that is filled visually should also be filled in the state. If a field is in the DOM but not in the state, the form filler is broken — or the form is.
3. Validation has re-run
After autofill, every required-field error should be gone, every "looks invalid" border should be reset, and any "fix this" message should clear. If they have not, the validators are listening to the wrong event.
4. The submit button is enabled
If your form's submit button enables based on internal state, this is a fast smoke test. Submit disabled = state did not update = autofill silently failed even though the screen looks fine.
5. Dependent fields have re-rendered
Country → state → city. Plan → seat count → total. Currency → tax. If any of these depend on a field the autofill touched, they should have updated. If they have not, your form is reading stale state.
6. Masked and formatted fields kept the data
Phone numbers, credit cards, dates, and currency fields often run formatting logic on input. When values arrive instantly, masks sometimes drop characters or insert wrong separators. Compare what you typed to what is in the field.
7. The submit payload matches the visible form
This is the most important check. Open DevTools → Network. Submit the form. Inspect the request body. Every field you see on screen should appear in the payload with the right value. Mismatches here are the bugs that ship.
8. Multi-step forms preserve values
If the form has multiple steps, autofill step one, advance to step two, return to step one, and confirm the values are still there. Then advance again and submit. Lost-on-back-navigation is one of the most common autofill bugs.
What to do when a check fails
Every failed check maps to a specific class of bug:
| Failed check | Likely cause |
|---|---|
| State does not match DOM | Form filler sets value but does not fire input/change events |
| Validation messages remain | Validators bound to keyup instead of input/change |
| Submit stays disabled | isValid derived from a stale state object |
| Dependent fields not updated | Cascade logic listens to a different event than autofill fires |
| Masked field dropped characters | Mask library does not handle instant value writes |
| Payload missing fields | Form library uses uncontrolled inputs without ref tracking |
| Lost on multi-step navigation | Step component unmounts and discards state instead of caching it |
The autofill checker workflow is what surfaces these. Without it, they all look like "user error" in production.
Why this matters more in 2026
Modern apps use more form libraries, more validation layers, more multi-step flows, and more locally generated state than five years ago. Every one of those layers is a place where autofilled data and visible UI can drift apart. The teams that ship clean form experiences are the teams that have a structured autofill checker pass in their QA process, not the teams that hope manual typing will catch the bugs.
Where MockFill fits
MockFill is built to make this checklist trivial to run. It fills realistic values, fires real browser events, and works on any form on any URL — so the checker workflow above is something you can do in a few minutes per form instead of an hour.
Install MockFill from the Chrome Web Store
Add a structured autofill check to your QA process this week:
- Install MockFill on Chrome
- Run the eight-point checklist on your most complex form. Track how many bugs you find on the first pass.
