[JENKINS-70662] Disable browser form validation from submit button

[aneveux]

See JENKINS-70662.

Hello 👋

As described in JENKINS-70662, and shared in the Jenkins 2.387.1 RC testing thread, a regression was introduced in Jenkins 2.376: Built-in validations are broken when inside an optionalBlock.

Prior to that version, validations were simply ignored when clicking on the submit button. The change introduced in #7203 though, transforming input type="button" in a button changed that behavior and led to that regression. The actual bug can be reproduced from #7666, leading to an error in the Javascript console when clicking the save button from the configuration: An invalid form control with name='_.someValue' is not focusable.

While there could be other solutions for this problem, the one proposed in that PR should be simple enough to cover most
cases. It seems that a similar approach was used in other places as well.

This PR should ideally be part of the 2.387 LTS, in order to avoid introducing a regression from the previous LTS.

Please let me know if anything is missing from this PR or if I could help in some other way 😄

Testing done

I did some manual testing for this PR, following the approach described in #7666.

I also tested it on some of our internal plugins facing the issue to confirm it was working fine.

Proposed changelog entries

• Disable unwanted browser form validation.

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples).
  • Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
• There is automated testing or an explanation as to why this change has no tests.
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@daniel-beck @jtnord @basil @jglick @Vlatombe

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[Wadeck]

Not manually tested but that was the expected outcome of our discussion 👍

[NotMyFault]

Thanks for investigating, and preparing a fix!

[NotMyFault]

/label ready-for-merge

---

This PR is now ready for merge. We will merge it after ~24 hours if there is no negative feedback.
Please see the merge process documentation for more information about the merge process.
Thanks!

[MarkEWaite]

I updated the proposed changelog entry to remove the content that will be automatically inserted by the changelog generator (PR number, issue number, regression fix) and to simplify the phrasing.

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

[jglick]

Were you able to figure out how to assert the bug case from #7666 using HtmlUnit?

[aneveux]

Were you able to figure out how to assert the bug case from #7666 using HtmlUnit?

I didn't even try TBH, I just relied on some manual testing.

[amuniz]

Manually verified against #7666