Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from Dec 4, 2023

Conversation

mawinter69
Copy link
Contributor

@mawinter69 mawinter69 commented Dec 2, 2023

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:
image

With fix:
image

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

Edit tasklist title
Beta Give feedback Tasklist Submitter checklist, more options

Delete tasklist

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

Desired reviewers

N/A

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

Maintainer checklist

Edit tasklist title
Beta Give feedback Tasklist Maintainer checklist, more options

Delete tasklist

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

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.
@MarkEWaite MarkEWaite added the bug For changelog: Minor bug. Will be listed after features label Dec 2, 2023
@MarkEWaite
Copy link
Contributor

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!

@MarkEWaite MarkEWaite self-assigned this Dec 2, 2023
@NotMyFault
Copy link
Member

Would you mind providing an "after" screenshot?

Copy link
Member

@NotMyFault NotMyFault left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@NotMyFault NotMyFault requested a review from a team December 3, 2023 19:28
Copy link
Member

@timja timja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/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!

@comment-ops-bot comment-ops-bot bot added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label Dec 3, 2023
@NotMyFault NotMyFault added regression-fix Pull request that fixes a regression in one of the previous Jenkins releases and removed bug For changelog: Minor bug. Will be listed after features labels Dec 4, 2023
@NotMyFault NotMyFault merged commit dc983d0 into jenkinsci:master Dec 4, 2023
17 checks passed
@daniel-beck
Copy link
Member

daniel-beck commented Dec 4, 2023

@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
Copy link
Contributor Author

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 NotMyFault added bug For changelog: Minor bug. Will be listed after features and removed regression-fix Pull request that fixes a regression in one of the previous Jenkins releases labels Dec 4, 2023
@NotMyFault
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug For changelog: Minor bug. Will be listed after features ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback
Projects
None yet
5 participants