Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-72196

UI is flickering when i save a job using 2 execute shells

    • 2.435

      Versions i saw this issue 2.387.3 and lts also.

      So, when i create a Jenkins job including 2 execute shells saving them and deleting the 1st one(execute shell), the other one when comes up starts flickering the screen. And it is unreadable when i want to make any changes in the job.

      I suspected the plugins first, but later when i freshly created a Jenkins server with the Jenkins recommended plugins also i encountered the same.

      I have attached the photos before and after, please check it.

       

      Thank you,

      Abhishek

          [JENKINS-72196] UI is flickering when i save a job using 2 execute shells

          Mark Waite added a comment -

          Thanks for the report. I've been able to duplicate the problem on my Jenkins 2.426 test instance. Steps that I took to duplicate the issue:

          1. Create a new freestyle job
          2. Add an execute shell step with the text "echo this is the first shell step"
          3. Add a second execute shell step with the text "echo this is the second shell step"
          4. Save the job definition
          5. Edit the job definition and remove the first execute shell step
          6. Confirm the web page looks wrong

          Mark Waite added a comment - Thanks for the report. I've been able to duplicate the problem on my Jenkins 2.426 test instance. Steps that I took to duplicate the issue: Create a new freestyle job Add an execute shell step with the text "echo this is the first shell step" Add a second execute shell step with the text "echo this is the second shell step" Save the job definition Edit the job definition and remove the first execute shell step Confirm the web page looks wrong

          Mark Waite added a comment -

          abhishek_02 are you interested in performing the git bisect to identify the commit that introduced the problem?

          Mark Waite added a comment - abhishek_02 are you interested in performing the git bisect to identify the commit that introduced the problem?

          Mark Waite added a comment - - edited

          abhishek_02 the behavior exists in some form all the way back to Jenkins 2.164.3, released 4 years ago. You'll need to use the workaround of saving the job after deleting the execute shell step, then open the job again with the configure link.

          Mark Waite added a comment - - edited abhishek_02 the behavior exists in some form all the way back to Jenkins 2.164.3, released 4 years ago. You'll need to use the workaround of saving the job after deleting the execute shell step, then open the job again with the configure link.

          abhishek added a comment -

          Thanks Mark for finding the timeline of that cause, appreciate the effort for the findings. I think it is the only way to do as you said save the job and again configure it.

          abhishek added a comment - Thanks Mark for finding the timeline of that cause, appreciate the effort for the findings. I think it is the only way to do as you said save the job and again configure it.

          abhishek added a comment -

          Is there a way to patch this issue?, because we have a few Jenkins servers where we have more than 1 subsequent  execute shells in use. will be a pain if this continues.

          abhishek added a comment - Is there a way to patch this issue?, because we have a few Jenkins servers where we have more than 1 subsequent  execute shells in use. will be a pain if this continues.

          Mark Waite added a comment -

          A fix for the issue seems possible if someone chooses to work on it. Considering how long the issue has existed and that this is the first time it has been reported, I do not expect any of the current maintainers of Jenkins core will decide to work on it.

          If you or someone from your company wants to work on it, you are welcome to do so. Pull requests can be submitted to the GitHub repository of Jenkins core.

          I don't understand why you changed the severity from trivial back to major. As far as I can tell, the only way to see the issue is by having two "Execute shell" steps (already rare, since a single execute shell step can include multiple lines) and then deleting the first execute shell step. The screen presentation is incorrect but the user can still save their changes to the job. Once the changes are saved, the screen presentation is correct once again.

          I only see misplaced text in my case. I don't see any flickering of the image when I use the most recent release of Google Chrome. Maybe you're using an outdated web browser? Maybe there is some detail missing from the report that makes the issue higher impact than I have seen?

          Mark Waite added a comment - A fix for the issue seems possible if someone chooses to work on it. Considering how long the issue has existed and that this is the first time it has been reported, I do not expect any of the current maintainers of Jenkins core will decide to work on it. If you or someone from your company wants to work on it, you are welcome to do so. Pull requests can be submitted to the GitHub repository of Jenkins core. I don't understand why you changed the severity from trivial back to major. As far as I can tell, the only way to see the issue is by having two "Execute shell" steps (already rare, since a single execute shell step can include multiple lines) and then deleting the first execute shell step. The screen presentation is incorrect but the user can still save their changes to the job. Once the changes are saved, the screen presentation is correct once again. I only see misplaced text in my case. I don't see any flickering of the image when I use the most recent release of Google Chrome. Maybe you're using an outdated web browser? Maybe there is some detail missing from the report that makes the issue higher impact than I have seen?

          Jenkins added a comment -

          The issue does seem more than trivial when you have a distributed user base who stumbles across the issue and begins to log multiple fix tickets against the issue.

          Pushing the responsibility to apply the workaround onto a wider user base could be challenging.

          Jenkins added a comment - The issue does seem more than trivial when you have a distributed user base who stumbles across the issue and begins to log multiple fix tickets against the issue. Pushing the responsibility to apply the workaround onto a wider user base could be challenging.

          Markus Winter added a comment -

          I was able to localize the problem.

          First I wasn't able to reproduce the problem on my regular instance, so I've set up another one with no plugins and then I could see the problem. The problem are the adjuncts for codemirror which are only included in the first div for the first shell. When you delete this, the codemirror.css is no longer included and the styles from there are not applied anymore

          So why didn't it happen on my regular instance? The answer is that there I have the Owasp Markup formatter installed and it is enabled. If this happens then the codemirror adjunct is already loaded as part of the description of the job, thus when removing the first shell step, the css is not lost. Going to "Manage" -> "Security" and then toggle the Markup Formatter from "Safe HTML" to "Plain Text" makes it visible.

          The solution would be to make s:adjunct inject the loading of the script and css not to appear at the place they are defined in the jelly but somewhere more to the top so they are not lost when deleting the first repeatable. That seems not so easy to solve.

          Markus Winter added a comment - I was able to localize the problem. First I wasn't able to reproduce the problem on my regular instance, so I've set up another one with no plugins and then I could see the problem. The problem are the adjuncts for codemirror which are only included in the first div for the first shell. When you delete this, the codemirror.css is no longer included and the styles from there are not applied anymore So why didn't it happen on my regular instance? The answer is that there I have the Owasp Markup formatter installed and it is enabled. If this happens then the codemirror adjunct is already loaded as part of the description of the job, thus when removing the first shell step, the css is not lost. Going to "Manage" -> "Security" and then toggle the Markup Formatter from "Safe HTML" to "Plain Text" makes it visible. The solution would be to make s:adjunct inject the loading of the script and css not to appear at the place they are defined in the jelly but somewhere more to the top so they are not lost when deleting the first repeatable. That seems not so easy to solve.

          Markus Winter added a comment -

          Have an idea for a fix. We can use Behaviour.specify (with A a negative index e.g. -1000 so it is run first) to find all links in the body and append them to the head.

          Markus Winter added a comment - Have an idea for a fix. We can use Behaviour.specify (with A a negative index e.g. -1000 so it is run first) to find all links in the body and append them to the head.

          Mark Waite added a comment -

          Thanks mawinter69. Your investigation also points to a workaround that abhishek_02 can use immediately. Install and enable the Owasp markup formatter.

          Mark Waite added a comment - Thanks mawinter69 . Your investigation also points to a workaround that abhishek_02 can use immediately. Install and enable the Owasp markup formatter.

            Unassigned Unassigned
            abhishek_02 abhishek
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: