Gravity Forms 3.1.0.2 fixes an issue where the button spinner could remain visible after an AJAX submission was aborted. The visible spinner is only one symptom. A canceled request can leave the button disabled, preserve a stale request token, attach duplicate listeners, create an entry after the visitor has retried, or fire analytics twice. The regression needs a controlled abort at several points plus reconciliation of browser requests, entries, notifications, feeds, and conversion events.
Use this when an AJAX Gravity Form remains busy after navigation, timeout, popup close, validation, network loss, rapid double click, consent change, or a custom AbortController action.
Quick answer
Update to the current Gravity Forms 3.1 patch, then throttle the network and abort a submission before send, during upload, after server receipt, and during response rendering. Confirm the spinner clears, the button becomes usable, one request owns the active state, and retry creates no more than one accepted entry. Correlate request ID, entry ID, notification, feed, webhook, and analytics event rather than judging only the button.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Before send | Immediate abort | Spinner clears and no entry |
| In flight | Throttle then cancel | State returns to ready |
| Server accepted | Abort before response | Retry does not duplicate entry |
| Popup reopen | Close and open twice | One listener and one request |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Map the AJAX lifecycle and custom handlers | Inventory custom AJAX listeners, AbortController code, popup lifecycle, multi-page navigation, file upload, consent handlers, optimization, and duplicate-submission protection. | Spinner and button state recover after every supported abort path. |
| Update to the current 3.1 patch | Capture button disabled state, spinner DOM, active request count, request payload, response timing, JavaScript events, console errors, and entry IDs. | The next valid submit sends one request and produces one accepted entry. |
| Run controlled abort fixtures | Abort before send, during a slow request, during upload, after server receipt, on route change, and by closing and reopening the popup. | Notifications, feeds, CRM, payment, and analytics do not duplicate. |
| Reconcile browser and server outcomes | Retry the exact same fixture and reconcile entries, notifications, feeds, CRM records, payment state, and analytics using stable IDs. | Repeated popup and AJAX renders keep one active submit listener. |
What to check first
- Inventory custom AJAX listeners, AbortController code, popup lifecycle, multi-page navigation, file upload, consent handlers, optimization, and duplicate-submission protection.
- Capture button disabled state, spinner DOM, active request count, request payload, response timing, JavaScript events, console errors, and entry IDs.
- Abort before send, during a slow request, during upload, after server receipt, on route change, and by closing and reopening the popup.
- Retry the exact same fixture and reconcile entries, notifications, feeds, CRM records, payment state, and analytics using stable IDs.
- Remove duplicate custom cleanup, keep one lifecycle owner, then retest on mobile, slow network, cache, and validation-error paths.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because cache purges, retries, scheduled actions, and deployments can change the evidence between tests.
- Test the public browser path and the server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, stored record, logs, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture=lead-17
request_id=req-8841
abort_stage=in-flight
spinner_after_abort=hidden
button_after_abort=enabled
retry_request=req-8842
accepted_entries=1
analytics_events=1
Why this usually happens
- The rejected or aborted promise bypasses the cleanup branch that removes the spinner and disabled state.
- Custom code and Gravity Forms both try to own the button lifecycle.
- The server accepts the first request even though the browser never receives its response.
- Reopening an AJAX form attaches another submit listener to the same button.
Decision rule
An aborted submission is safe only when the interface returns to a known state and the retry remains idempotent. A hidden spinner without entry reconciliation is incomplete.
Production verification checklist
- Spinner and button state recover after every supported abort path.
- The next valid submit sends one request and produces one accepted entry.
- Notifications, feeds, CRM, payment, and analytics do not duplicate.
- Repeated popup and AJAX renders keep one active submit listener.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Map the AJAX lifecycle and custom handlers
- Update to the current 3.1 patch
- Run controlled abort fixtures
- Reconcile browser and server outcomes
- Remove duplicate ownership and retest retry
Mistakes to avoid
- Changing production code, cache settings, form fields, webhook endpoints, or firewall rules before preserving the exact failure, current versions, and rollback point.
- Treating one successful page load or dashboard status as proof while browser behavior, PHP logs, scheduled jobs, delivery records, and downstream data remain unchecked.
- Testing a different role, device, locale, form, URL, order state, cache state, or plugin combination than the workflow that users actually reach.
- Leaving helper plugins, debug logging, copied secrets, broad exclusions, temporary endpoints, or test notifications active after the verification window.
Questions teams ask during testing
Can I run this directly on production?
Begin with read-only checks and preserve evidence. Use staging for changes that affect PHP, cache generation, form submission, payment, email, or customer state. When production is necessary, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Match the exact plugin and WordPress versions, URL, role, device, locale, cache state, and integration path. Repeat the same fixture before and after the change, then compare stored evidence rather than relying on memory.
What evidence should I keep?
Keep UTC time, versions, affected URL or record ID, expected result, actual result, relevant log lines, configuration snapshot, change made, rollback point, and final verification. Remove credentials, payment details, and personal data.
When should I bring in a specialist?
Escalate when the site is unavailable, checkout or lead capture is affected, a security boundary is unclear, several systems disagree, or the next step could destroy evidence. A concise incident packet makes outside help much faster.
What to tell the client or owner
Give the owner a short evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected and actual result, key logs, the change made, rollback point, final result, owner, and next review date. Redact credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP repair the Gravity Forms AJAX submission lifecycle.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references