[JENKINS-72196] avoid wrong styling when deleting the first of 2 shell steps

[mawinter69]

fixes JENKINS-72196 when in a form there are repeatables that both contain a codemirror config via a textarea. When deleting the first of those it can happen that the link elements importing the css for codemirror are defined in a div that gets deleted. This effectively removes the css from the DOM tree, so that other textareas afterwards that also require the codemirror css are no longer styled properly.

The Behaviour uses a high negative value for the priority so that the move of the link elements is applied before any other behaviour jumps in, e.g. hetero-list and repeatable add the elements to the dom via jelly of all things can that can be added and later remove them from the dom and keep them in memory so they can be injected when clicking the add button.

See JENKINS-72196.

Without fix:

With fix:

Testing done

Manual testing as described in the Jira ticket.

No automated testing because automation of this area is expensive and provides little value. Bug has existed and been unreported for many years.

Proposed changelog entries

• Avoid incorrect styling when deleting the first of two shell steps in a job definition.

Proposed upgrade guidelines

N/A

Submitter checklist

Beta Give feedback

1. The Jira issue, if it exists, is well-described.
2. 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.
3. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. 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).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

N/A

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

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. 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).
6. 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).

[MarkEWaite]

I confirmed with interactive testing of the pull request that without this change, when the first shell step is deleted from the job, the styling of the second shell step is incorrect on the visible form. With this change, the styling of the second shell step remains correct after the first shell step is deleted. Thanks very much!

[NotMyFault]

Would you mind providing an "after" screenshot?

[NotMyFault]

Thanks!

[timja]

/label ready-for-merge

---

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!

[daniel-beck]

@NotMyFault Why regression-fix? Mark wrote in Jira,

the behavior exists in some form all the way back to Jenkins 2.164.3, released 4 years ago

and it's unclear to me whether this implies it broke in 2.164.3, or whether he didn't test further. Have you determined when this worked?

[mawinter69]

I could verify that the same problem exists on a 2.60.3 instance (not as severe as it was now due to different styling) . My guess is that it existed from the beginning.

[NotMyFault]

I could verify that the same problem exists on a 2.60.3 instance (not as severe as it was now due to different styling) . My guess is that it existed from the beginning.

Thanks for the pointer. I was under the impression that this pr addresses a regression