Submit

The single most important property of this SDK: your form is still the submit path.

The <form> element, its action, its method, its inputs and its submit button are never replaced, never proxied and never re-implemented. The agent fills the real inputs; the visitor presses the real button; your handler runs exactly as it does today.

The confirm step

Under the default data-nam-submit="confirm", once every required field is filled the agent reads back what it has — locked fields excluded — and waits.

In panel layout the panel docks back inline at this point, so the disclosure the visitor reads and the button they press are your page's own, in their own context, with your own copy above them. The button is brought into view and outlined; nothing presses it for them.

The panel docks, and the page's own button is the one pressed.

auto

<form data-nam-submit="auto" …>

The form is submitted as soon as the agent asks. The SDK tries requestSubmit(button) first so that your submit listeners and constraint validation both run, then button.click(), then form.submit() as a last resort.

Use it only where there is no consent language on the page. If there is, the visitor should be the one to press.

How values reach your inputs

Writes go through the prototype value setter, not the instance property, so React and mask plugins that patch the instance setter still observe the change. Then events fire in order:

• text-like controls: input → keyup → change → blur
• select, radio, checkbox: input → change

Your existing masks, validators and analytics listeners see exactly what they would see if a person had typed it.

The SDK also listens on your form in the capture phase for input and change, so a listener of yours that stops propagation cannot hide an edit from it. Its own writes are flagged and ignored, so there is no echo loop — and a password-manager autofill is picked up after a 400 ms settle.

Nothing is written until it is confirmed

A chip or select pick is written immediately — the visitor chose it.

Typed text is not. It goes to the agent as a message naming the open field, and only reaches your input once the agent has read it and issued a set_field that passes the server's provenance check. That check compares the value the agent wants to write against what the visitor actually said; for a tel or number field it compares on digits alone, so reformatting is allowed and retyping a digit is not.

What happens at the moment of submit

Around your ordinary submission, the SDK:

• marks the page submitted in session storage, so a back-button return does not land on a live-looking thread over a closed stream;
• sends one lp_submit beacon with the final snapshot — field states and counters, never typed values — using keepalive so it survives the navigation;
• keeps helping afterwards where the campaign says to, using the phone or email written to the profile.

Field values pass through memory for that one profile write and are never persisted a second time. The session row stores which fields are filled, valid and required — not what was typed.

Every failure returns your form

restore() is called on every failure path: a stream that will not connect within 8 seconds, a greeting that does not arrive within 12, two failed posts in a row, a 403 on the origin, or any thrown error inside the controller — every entry point runs inside a guard.

It reverses every DOM change the SDK made, unmounts the widget, and leaves the form the visitor would have had anyway. In the panel case it also restores the page's scroll and clears inert.

The end-to-end suite asserts this by comparing the form's HTML byte for byte against its state at boot, for both a wrong key and a failed session.

The back button

Returning to a submitted page shows the page, not a dead conversation: the submitted marker is read from session storage and the SDK does not re-open. A bfcache restore that was not a submit reconnects the stream instead, so a visitor who wandered off and came back carries on where they were.