Fall back to first-error focus when the error summary isn't rendered

[vivi-the-going-merry]

What was broken

js_validate's client-side path (validateFormSubmit() -> addAjaxFormErrors(), js/formidable.js ~2591) never renders the [data-frm-error-summary] markup - it only calls addFieldError() per field. checkForErrorsAndMaybeSetFocus() still resolved config.focusErrorSummary true (the summary is "active" per filter, independent of whether js_validate is enabled) while config.focusFirstError was forced false server-side (mutually exclusive with the summary, see FrmAppHelper::resolve_error_focus_target()). Net effect: a failed submit on a form with "Validate Fields as User Completes Form" enabled focused nothing at all - worse than the pre-formidable-forms#3408 behavior (first errored field).

What changed

checkForErrorsAndMaybeSetFocus(): when the summary is expected (focusErrorSummary true) but isn't actually found in that error's own form container, fall through to the existing first-errored-field focus logic instead of returning early. No change when the summary is genuinely rendered (unaffected), and no change when an integration deliberately filters both frm_focus_first_error and frm_focus_error_summary off (still no auto-focus).

js/formidable.min.js: hand-mirrored the same one-condition change into the matching minified function (js_suffix() serves this file whenever SCRIPT_DEBUG is off) - not independently executed locally, verified by direct text diff against the source change plus node --check.

tests/cypress/e2e/Forms/fieldsInFormBuilder-validation.cy.js: added a have.focus assertion to the existing "should validate forms with javascript setting" test, on the submit click where only the required Text field is invalid (email/phone already valid format there, avoiding native browser constraint-validation interference on the other submit click in the same test).

How verified

Local: real Cypress run (npx cypress run) against a local wp-env WordPress instance with js_validate enabled via the form builder UI - confirmed red (assertion timeout) against unfixed code, green after the fix, and red again when the fix was temporarily reverted with the test kept. CI: see checks on this PR.

Fixes Strategy11/formidable-pro#6763

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: Strategy11/formidable-forms/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 272aa759-45ec-4e66-ae7d-8a73b6784408

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[vivi-the-going-merry]

CI: all green except two pre-existing/unrelated failures, both confirmed rather than assumed:

• Cypress shard 1 — Form Templates/FormTemplates.cy.js: same spec/failure signature also hit an unrelated concurrent PR (fix/issue-3430-removefield-fid-assertion, run 36251620035) ~1.5h earlier today — a pre-existing flake, not caused by this diff (which only touches js/formidable.js, its compiled sibling, and a Cypress validation spec, none of which are form-templates related).
• Run Stylelint — resources/scss/admin/components/settings/_misc-components.scss:13: confirmed identical on origin/master (line-for-line) — pre-existing violation this PR's diff never touches, inherited via the earlier master merge, not introduced here.

Self-review (code-review/security-review/simplify) run against the diff. One code-review finding investigated and ruled out: whether the new ! config.focusFirstError && ! config.focusErrorSummary fallback could override a site's explicit frm_focus_first_error => false filter. Traced FrmAppHelper::should_focus_first_error() — its default already resolves to false whenever the error summary is active (classes/helpers/FrmAppHelper.php:4183-4189), so an explicit filter to false in that state is a no-op indistinguishable from default; there's no reachable case where this fallback fires only because of the filter rather than the (identical) default. No change made.

Ready for review.