Gravity form not submitting: check the top

A long form puts its Submit button at the end, so a visitor finishes at the bottom of the page. A failed check on a required field can return the form with an error summary above the first field, which may be a long way up the screen. A good submit can replace the form with a thank you line in the same spot at the top. The visitor's view stays where it was, so nothing appears to change. Some visitors press Submit again, and some leave. The owner who tests from the top of the page sees the result at once and never meets the problem.

• Scroll to the bottom and press Submit. Note whether the page moves, and where the first message appears.
• Leave the form empty and press Submit. Check whether the error summary is visible without scrolling up.
• Send a valid form and check whether it is replaced by a thank you line or sent to another address.
• Open the address after a good submit. A redirect to a missing page looks like a blank screen.
• Open the browser console at the press. A refused request leaves no visible change at all.

Gravity Forms can report a failed check at the top of the form, so the validation summary may sit several screens above the button. The summary lists the fields that need attention, and the first one may be several screens above the visitor's thumb. The confirmation type decides what happens after a good submit: a message in place of the form, or a redirect to another address. Each choice is sensible on a short form. On a long form, each one can happen out of sight, and the visitor reads the silence as a broken button.

A phone makes this worse. The screen is short, so the whole form can sit above the fold, and the visitor at the bottom sees only the Submit button. A desktop owner has a tall window that shows the summary without any scrolling, so the fault never appears on the screen the owner uses to test. Test on a phone, from the bottom of the form, before you trust the page.

A failed submit and a good one can both leave the visitor where they were. Compare what changed. A visible error message or a highlighted field shows a failed check. A thank you line, a new address or a page that loads show a success. If nothing changed and the page did not move, open the console and press Submit again. A request the browser refused produces the same silence as a validation error that sits out of view, so the console is the only place the two differ.

A simulated visitor fills the form from the top, scrolls to Submit as a person would, presses it, and records what changed. The report gives the step, a screenshot of the screen after the press, and any failed request logged at that point. The run does not read your confirmation settings or your notification setup, so it cannot tell you which message type you chose. It shows where the visitor's eye would have to go to find the result, and that is the place to move it.

Each new section pushes the Submit button further down. A field added in the middle, a longer intro or a new section can move the error summary out of the visitor's view, and the fault returns without any change to the submit itself. After each edit, press Submit from the bottom of the form on a phone and check where the result appears.