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

Adding different colors to history table and data filter

    • Jenkins 2.105

      When I start or refresh a job page, the build history alternating colors start with white on the filter textbox, then grey/white/grey/white for the builds. Also, after using the filter box, or even clearing an already empty filter, the colors clashe with the filter textbox having grey, and them white/grey/white/grey for the builds. It seems that color alteration are not in the right order

      It is an inconsequential issue as the rest of page and features work very well.

      I think there are some minor issues with html element rendering.

          [JENKINS-59631] Adding different colors to history table and data filter

          Hi all,

          I would like to work on fixing this. I am a newbie to this project so i hope you all will help me until i get a hang of the system.  Can you kindly provide me with a screenshot of the page where this issue occurs so that i can recreate and start working on this?

          Kalana Wijethunga added a comment - Hi all, I would like to work on fixing this. I am a newbie to this project so i hope you all will help me until i get a hang of the system.  Can you kindly provide me with a screenshot of the page where this issue occurs so that i can recreate and start working on this?

          Daniel Beck added a comment -

          kalana Thanks for your interest. This is a job's build history, e.g. on the left of https://ci.jenkins.io/job/Core/job/jenkins/job/master/

          When you load the page, the background of the filter field near the top is white, and the topmost build has a grey background.

          Enter the number "7" into the filter field and press Enter: It will now have a grey background, and the topmost build has a white background.

          Daniel Beck added a comment - kalana Thanks for your interest. This is a job's build history , e.g. on the left of https://ci.jenkins.io/job/Core/job/jenkins/job/master/ When you load the page, the background of the filter field near the top is white, and the topmost build has a grey background. Enter the number "7" into the filter field and press Enter: It will now have a grey background, and the topmost build has a white background.

          I was able to reproduce this. I have attached the image herewith for your verification. I will start working on this. I would be thankful if you could provide me with some guidance on where should i look for this HTML/CSS files

          Kalana Wijethunga added a comment - I was able to reproduce this. I have attached the image herewith for your verification. I will start working on this. I would be thankful if you could provide me with some guidance on where should i look for this HTML/CSS files

          I have investigated the issue and identified that the issue is due to the following code in style.css

          table.stripped tr:nth-child(even) {
          {{ background: #fbfbfb;}}
          }

          The table under the build history has the classes "stripped" and "pane" and its alternating colors are created by the above css. 

          The reason for the issue is that at the job page, first row which is the search bar acts as an odd child and when we enter something in it, it acts as an even child of the table. Ideally it should stay as an odd child as in css children are started from 1. 

          Can someone tell me the path to the HTML file of the job page so that I can investigate why this is happening?

          Kalana Wijethunga added a comment - I have investigated the issue and identified that the issue is due to the following code in style.css table.stripped tr:nth-child(even) { {{ background: #fbfbfb;}} } The table under the build history has the classes "stripped" and "pane" and its alternating colors are created by the above css.  The reason for the issue is that at the job page, first row which is the search bar acts as an odd child and when we enter something in it, it acts as an even child of the table. Ideally it should stay as an odd child as in css children are started from 1.  Can someone tell me the path to the HTML file of the job page so that I can investigate why this is happening?

          On further investigation i identified that the issue was due to the following reason.

          On job page the rows under the table build history are created inside <tbody> tag, but when we enter a search query into it table rows get created outside the <tbody> tag. Therefore <tbody> tag becomes the first child which transforms the search bar row into the second child. As <tbody> is empty, it is not shown to the user and therefore its color is not visible to the user, instead search bar will be visible with the color of the second child.

          There are 2 solutions to this.

          1. Using "nth-of-type" css tag instead of "nth-child" which considers children of same type only.
          2. Even after the search query, add the table rows inside the <tbody> tag

          I believe 2nd approach would be the best way and 1st approach is just a workaround to the same. 

          danielbeck could you please advise me on how to proceed?

          If we are following the second approach, could somebody please show me where the HTML and JS files relevant to this page are located?

          Kalana Wijethunga added a comment - On further investigation i identified that the issue was due to the following reason. On job page the rows under the table build history are created inside <tbody> tag, but when we enter a search query into it table rows get created outside the <tbody> tag. Therefore <tbody> tag becomes the first child which transforms the search bar row into the second child. As <tbody> is empty, it is not shown to the user and therefore its color is not visible to the user, instead search bar will be visible with the color of the second child. There are 2 solutions to this. Using "nth-of-type" css tag instead of "nth-child" which considers children of same type only. Even after the search query, add the table rows inside the <tbody> tag I believe 2nd approach would be the best way and 1st approach is just a workaround to the same.  danielbeck could you please advise me on how to proceed? If we are following the second approach, could somebody please show me where the HTML and JS files relevant to this page are located?

          Daniel Beck added a comment -

          Re the files, they're a fairly convoluted mess. https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/widgets/HistoryWidget/index.jelly is probably the best starting point. https://github.com/jenkinsci/jenkins/blob/ef85b89323d4ecb69f96bb2da80282a5a19e2fa4/war/src/main/webapp/scripts/hudson-behavior.js#L1937-L2158 seems to be related JS.

          I agree that approach 2 seems superior. Alternatively we could remove tbody (assuming no negative side effects) if it's easier to do, at least then there would be consistency between initial and updated UI.

          Daniel Beck added a comment - Re the files, they're a fairly convoluted mess. https://github.com/jenkinsci/jenkins/blob/master/core/src/main/resources/hudson/widgets/HistoryWidget/index.jelly is probably the best starting point. https://github.com/jenkinsci/jenkins/blob/ef85b89323d4ecb69f96bb2da80282a5a19e2fa4/war/src/main/webapp/scripts/hudson-behavior.js#L1937-L2158 seems to be related JS. I agree that approach 2 seems superior. Alternatively we could remove tbody (assuming no negative side effects) if it's easier to do, at least then there would be consistency between initial and updated UI.

          I will have a look on this and send a PR soon

          Kalana Wijethunga added a comment - I will have a look on this and send a PR soon

          danielbeck the tbody tag is automatically created with the pane.jelly used in the HistoryWidget component. So I believe removing the tbody tag is not an option as it might have adverse effects if this component is used in somewhere else. Its hard to guarantee that updating the JS won't affect somewhere else as well. 

          So shall we go with option 1? This will fix if there are any inconsistencies in the other tables as well and it looks to me that it is the least harmful option as it is less likely to cause any damage to other components.

          Kalana Wijethunga added a comment - danielbeck the tbody tag is automatically created with the pane.jelly used in the HistoryWidget component. So I believe removing the tbody tag is not an option as it might have adverse effects if this component is used in somewhere else. Its hard to guarantee that updating the JS won't affect somewhere else as well.  So shall we go with option 1? This will fix if there are any inconsistencies in the other tables as well and it looks to me that it is the least harmful option as it is less likely to cause any damage to other components.

          Can we take a decision on this so that we can have a fix and close this issue?

          Kalana Wijethunga added a comment - Can we take a decision on this so that we can have a fix and close this issue?

          Please find the link to the PR below

          https://github.com/jenkinsci/jenkins/pull/4342

          Kalana Wijethunga added a comment - Please find the link to the PR below https://github.com/jenkinsci/jenkins/pull/4342

            kalana Kalana Wijethunga
            mattumd Matt Zand
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: