Audit a Form and Fill It with Test Data

The Developer role in WTFAA has two actions for forms. Form Audit reviews the structure of the forms on the current page. Fill Test Data proposes fake values for the visible fields and writes them into the page only after you confirm.

This guide explains what both actions read from the page, what they return, and what the fill step does not do. If you have not set up WTFAA yet, start with Getting started. For an overview of the three roles, see Reader, Designer and Developer roles.

What WTFAA reads from the form

Both actions read the form structure locally from the active tab:

• Only <form> elements with at least two controls are collected. Forms hidden with an inline style are skipped, and fields that are not inside a <form> element are not included.
• For each form: its heading or legend, the text inside the form, and the form's action URL and method.
• For each field: tag, type, name, id, label, placeholder, the required flag, and the current value.
• Inputs with type="hidden" and fields hidden with an inline display: none are not collected at all.
• The page URL, the page title, and a short summary of frontend signals found on the page.

Chrome does not allow extensions to run on restricted pages such as chrome:// pages or the Chrome Web Store, so these actions do not work there.

Step 1: Check the send preview

Clicking either action opens Review before sending first. For a form request it shows the page URL and title, the number of forms and fields, the model, and the mode.

Under Local redaction, the preview lists what the local filter found. Password fields are always reported there. A field counts as a password field when its type is password or when its name, id or label contains "password", "passcode" or "pin". With Use locally filtered context turned on, the values of these fields are replaced with [REDACTED_PASSWORD] before sending. The option is turned on automatically whenever the filter finds something; if you turn it off, the unfiltered values are sent.

Click Send to AI to continue, or Cancel to stop. The preview options are explained in What is sent to the AI.

Step 2: Run Form Audit

1. Open the page that contains the form.
2. Open the WTFAA side panel and switch to the Developer role.
3. Click Form Audit.
4. Check the preview and click Send to AI.

The report has three parts:

• Field Summary: a table with each field's type, label, required status and validation.
• Dependencies: conditional logic between fields.
• Potential Issues: visible problems with usability, labels, required states and client-side validation.

The audit reads validation only from visible HTML attributes, client-side hints, displayed error states and field relationships. It does not infer server-side validation rules, and it marks unknown backend rules as unknown.

Step 3: Generate test data with Fill Test Data

1. On the same page, click Fill Test Data.
2. Check the preview and click Send to AI.
3. The model replies with a short note and one structured JSON action. The action lists a CSS selector and a value for each field. The request asks the model to use realistic but fake data, to prefer selectors based on the field's id or name, and to include only visible fields from the form context.
4. When the reply is complete, WTFAA shows a 💡 Suggested Action card. It states how many fields will be filled and lists each selector and value under Fields to review before filling.

Step 4: Review the fields and confirm

Check every row in the card. Nothing is written into the page until you click One-click Execute.

When you click it, WTFAA fills the fields in the active tab of the current window and briefly highlights each field it filled. Keep the tab with the form active when you click. Selectors that match nothing on the page are skipped.

The card does not let you edit or remove single rows. If a row should not be filled, do not run the action: ask for new data in the chat, or fill those fields yourself.

How the values are applied

• Text inputs and text areas: WTFAA sets the value through the browser's native value setter, updates React's internal value tracker, and then fires focus, input, change and blur events. This lets React-controlled inputs register the new value.
• Select menus: the value is matched against option values first, then against option text, then used as an option index.
• Checkboxes and radio buttons: true, 1, checked or on checks the box; any other value unchecks it. Since version 1.3.4, these changes also update React-controlled form state.

Since version 1.3.2, WTFAA does not run AI-generated JavaScript. The fill action is plain JSON data, and the code that applies it is built into the extension.

What the fill step does not do

• It does not submit the form and does not click submit buttons or any other buttons. The fill code only sets field values and fires input events. Submitting the form is up to you.
• Hidden inputs are never sent to the model, so they are not part of the proposed data.
• The request tells the model not to include hidden fields, password fields, payment fields, terms checkboxes, submit buttons or destructive controls, and not to trigger payments or accept terms. This is an instruction to the model, not a technical block. The field list in the card is your check: if it contains a terms checkbox, a payment field or a password field, do not run it.

Tips

• Use Fill Test Data on test or staging environments. The values are fake and are not meant for real submissions.
• If the preview shows 0 forms, the page probably builds its form without a <form> element, which WTFAA does not collect.
• To ask about something else on the page, see Translate a page or Analyze a screenshot.