A. Core submission flows
- Mail target, standard submission (page reload) — success message shows, page redirects back to itself
- Mail target, async submission (
Async submissiontoggle on) — no reload, status appears inline, submit button disables while in flight - API target, POST — webhook.site shows the fields arriving correctly
- API target, GET — fields arrive as a query string
B. Field type coverage
Add one of each to a test form and confirm each renders and submits correctly:
- Text (with and without a validation pattern, e.g.
^\d{5}$) - Number (set min/max/step — try the browser’s native spinner, and try typing an out-of-range value manually)
- Date, Time
- Textarea
- Checkbox (leave unchecked — confirm it’s treated as empty, not an error, unless required)
- Radio group with 3+ options
- Select
- File — single, then toggle “Allow multiple files” and pick 2+ files
C. Validation & error handling
- Submit with a required field empty → error shown next to that field, focus/visual indication makes sense
- Invalid email format
- Number outside configured min/max
- Text not matching the configured pattern
- Wrong file type / oversized file (set a small “Max file size” like 0.01 MB to trigger it easily)
- Multiple invalid fields at once — all errors show, not just the first
- After a failed standard (non-async) submission, confirm previously-typed values are restored (not wiped) — except the file field, which browsers never let you refill programmatically
D. Bug-fix regressions (specific to this session’s fixes)
- Name a text field “First Name” (with a space), mark required, submit filled in → no false “required” error
- Same field: put
[First Name]in the mail message template → confirm it resolves in the sent message body (check via webhook.site if using API, or the fallback-listing check below) - Radio group: click each option’s label (not the dot itself) → confirm it selects that specific option, not always the first one
- Leave “Message template” blank on a mail-target form, submit successfully → resulting email/API payload lists all submitted fields instead of being empty
- Set target=API, method=GET, add a file field, submit with a file selected → webhook.site shows the request arrived as POST with the file attached, not GET with the file silently dropped
- Create two different forms (different pages) with identical recipient/method/message/headers but different fields → submit both → each validates against its own fields, doesn’t get confused by the other
E. Security-fix regressions
- View page source on a form that previously failed validation → confirm you see
, not rawwindow.fbValues =JS assignments - Submit a form, then immediately resubmit within 5 seconds → second attempt shows "submitting too quickly"; wait 6+ seconds → works again
- Open the form field's honeypot input via devtools (
input[name="fb_hp"]), give it a value, submit → get a normal-looking success message, but confirm nothing actually arrives (webhook.site / MailHog empty) - Log in as an Author/Editor (not Administrator) and open a page with the form block → confirm "Additional headers" is not visible in the inspector at all
- As Administrator, set "Additional headers" to something with 3 email addresses in one
Bcc:line, submit → confirm (via API target headers echoed by webhook.site) that header was dropped, not forwarded - Try uploading a disallowed file type (set "Allowed file types" to
jpg,pngand upload a.pdf) → rejected with a clear message
F. UX checks
- Tab through the whole form with keyboard only — honeypot field should never receive focus
- "* Required fields" note only appears when at least one field is actually required
- Inline radio/checkbox groups look reasonable on mobile width
- Editor: inserting each field block shows a sensible disabled preview; Number block's min/max/step controls and File block's allowed-types/max-size controls all behave as expected
- Note (not necessarily a bug, just observe): there's no client-side warning if a selected file exceeds the configured max size before submitting — the error only appears after the round-trip. Worth deciding if that's acceptable or something to improve later.
G. Quick sanity pass
- Browser devtools console shows no errors/warnings on either the frontend page or the block editor
- Test in a second browser if convenient, just to catch anything browser-specific