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

Regression of "short messages" with Badge 1.10

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • 1.12

      NOTE: Initially reported and explored in Gitter: https://matrix.to/#/!HKutvjxPnajVyCNLhF:matrix.org/$Tq-nW8L-nZUTufZerUeNEE8cn4bHtH0uEyuQyOQZrhU?via=gitter.im&via=matrix.org&via=mozilla.org

       

      After the recent update of the Badge plugin, the "yellow boxes" in the classic interface left-column list of jobs have changed to be gray (old ones are still yellow) and are no longer wrapped for long entries so they do not fit into the column (also impacts message boxes rendered for old builds). Their text also can not be selected and copied into a clipboard (old boxes on the same page can).

      Are these particular changes critical for the new version's changed workings, or can their UX be un-broken back? Is this something as simple as a (perhaps local) patch to CSS? (UPDATE: Further experiments confirmed that at least the worst "offenses" can be amended by CSS, although I could not make it persistent yet).

       

      • Old-builds' boxes, some fitting and some skewed :
      • Text could be selected there:
      • New boxes: gray, unselectable, and not wrapping:
      • For shorter messages, things do fit well (separate boxes are wrapped around separately):
      • They were supposed to look like this (seems, a Firefox run-time F12 tweak to badges/assets.css for white-space: normal and text-align: right restores this bit of behavior):
      • The yellow and gray badges seem to have different CSS styles (makes sense):

      • ...Or in markup detail, NEW GRAY:

        ...vs. OLD YELLOW (note the in-line style):

       

      I'm still at a loss what CSS property combo loses the ability to select and copy the text (is it the use of ::before then message then ::after so it is not quite a tagged text?), or for that matter even what makes the box gray (the original yellow was apparently via inline style background of each div separately,with a grayish border remaining; maybe the new lack of filling is that gray background which was always there being not only the border now)?

      Experimentally, I've tried editing that instance's $JENKINS_HOME/userContent/jenkins.css (as configured to be used), adding this CSS section: 

      /* Align to markup of badges before plugin 1.10 */
      .badge-shortText {
        border: 1px solid #C0C000;
        background: #FFFF00;
        color: #000000;
        white-space: normal;
        text-align: right;
      } 

      However the CSS in the plugin seems to take priority over this one. In F12 I can un-tick the text-align and white-space items coming from plugin's assets.css and then the boxes change form to expected size (at least, the old ones do; new ones seem to ignore it anyway - but currently a build is running and the pane keeps refreshing, so it is not easy to check in real time).
       
       
      With this edit, the message boxes became dark-yellow; F12 clicking away of .badge-shortText--default-background::before setting for background: currentColor seems to make them all-yellow (losing the darker border):

      It seems there is some virtual canvas whose width now dictates all boxes' sizes. Even though the new box became "wrapped" (as seen in build #19 above), it aims for something larger than the builds panel and pulls the old boxes along into the abyss.

       

      UPDATE: Following a suggestion to add !important modifiers to the custom CSS, I got the overrides working: 

      .badge-shortText {
        border: 1px solid #C0C000 !important;
        background: #FFFF00 !important;
        color: #000000 !important;
        white-space: normal !important;
        text-align: right !important;
      }

      Now it looks much more usable (yellow being still different though, and text still not selectable, but counts as a quick workaround for my taste and pressing needs):

       

      FURTHER UPDATE:

      The dark-yellow is ultimately because of a combination of .badge-shortText--default-background::before items opacity and background: currentColor (originating from e.g. .badge-shortText color but not purely it... setting that one to blue I get a purple/magenta haze here).
      So in the latest screenshot above effectively it lays a greyish mask over the requested yellow background.

       

      Setting opacity: 0 to effectively ignore the ::before "pseudo-element" (as the browser calls it), I get the normal yellow (see just below): 

      /* Align to markup of badges before plugin 1.10 */
      .badge-shortText {
        border: 1px solid #C0C000 !important;
        background: #FFFF00 !important;
        opacity: 1 !important;
        color: #000000 !important;
        white-space: normal !important;
        text-align: right !important;
      }
      .badge-shortText--default-background::before {
        opacity: 0 !important;
      } 

      Here, old and new boxes look the same (new is still not clickable to select - note different mouse cursors):


       
       
      For kicks, with .badge-shortText color: #0000FF (blue) and ...::before opacity: 1 I get purplish text in older boxes and purplish background (in newer ones melding with the same-color text):
       
       

       
      With opacity 0.8 the text is barely visible, but the colors do differ (so it is not overlaying the whole content, per se):
       

       
       

          [JENKINS-73167] Regression of "short messages" with Badge 1.10

          Mark Waite added a comment -

          Thanks for the details! strangelookingnerd may also be able to investigate it before I do.

          Mark Waite added a comment - Thanks for the details! strangelookingnerd may also be able to investigate it before I do.

          Thanks for the in-depth investigation, helps me out a lot already to follow through what's going wrong in your example.
          I'm currently able to reproduce the behavior you describe and will soon come up with a solution that should solve most, if not all regressions due to the latest changes.

          Daniel Krämer added a comment - Thanks for the in-depth investigation, helps me out a lot already to follow through what's going wrong in your example. I'm currently able to reproduce the behavior you describe and will soon come up with a solution that should solve most, if not all regressions due to the latest changes.

          jimklimov Could you please verify if the issue still persists with the latest 1.12 release? At least in my local reproducer seems to be fine now but maybe yours differs.

          Daniel Krämer added a comment - jimklimov Could you please verify if the issue still persists with the latest 1.12 release? At least in my local reproducer seems to be fine now but maybe yours differs.

          Jim Klimov added a comment -

          FYI UPDATE: During later investigation I've realized we are also using Groovy Postbuild (Version 228.vcdb_cf7265066) which builds upon Badge, and may impact the style (yellow and rounded boxes that we're used to may be its achievement - at least per https://github.com/jenkinsci/badge-plugin/pull/158 "native" messages from Badge may have been not as pretty).

          Jim Klimov added a comment - FYI UPDATE: During later investigation I've realized we are also using Groovy Postbuild (Version 228.vcdb_cf7265066) which builds upon Badge, and may impact the style (yellow and rounded boxes that we're used to may be its achievement - at least per https://github.com/jenkinsci/badge-plugin/pull/158 "native" messages from Badge may have been not as pretty).

          Jim Klimov added a comment -

          As for trying with a newer release - lately that CI farm was busy, I'll sneak in the update to check when possible (1.13+ by now).

          Jim Klimov added a comment - As for trying with a newer release - lately that CI farm was busy, I'll sneak in the update to check when possible (1.13+ by now).

          Jim Klimov added a comment -

          Updated a server to Badges 1.13 today.

          No CSS style is assigned to the text elements at all now, so they look like tombstones with a thick border (not like the rounded yellow boxes I had in earlier screenshots above), sizes are good though :\

          An SVG icon does have the icon-sm style assigned.

           

          It is actually interesting to see the older builds that have two styles (or absences there of, with hard-coding either way) on the same page:

          The divisive 858/857 builds' markup is:

           

          Jim Klimov added a comment - Updated a server to Badges 1.13 today. No CSS style is assigned to the text elements at all now, so they look like tombstones with a thick border (not like the rounded yellow boxes I had in earlier screenshots above), sizes are good though :\ An SVG icon does have the icon-sm style assigned.   It is actually interesting to see the older builds that have two styles (or absences there of, with hard-coding either way) on the same page: The divisive 858/857 builds' markup is:  

          Jim Klimov added a comment - - edited

          As I've mentioned before, this system has https://plugins.jenkins.io/groovy-postbuild (at 228.vcdb_cf7265066, 6 months old now) which I suppose builds upon the badge-plugin, and imposed the user-requested or default style onto the message boxes, and that could be behind the in-lined yellowness I am so used to.

          The new build of Badge 1.13 seems to override that rudely :\

          Jim Klimov added a comment - - edited As I've mentioned before, this system has https://plugins.jenkins.io/groovy-postbuild (at 228.vcdb_cf7265066, 6 months old now) which I suppose builds upon the badge-plugin, and imposed the user-requested or default style onto the message boxes, and that could be behind the in-lined yellowness I am so used to. The new build of Badge 1.13 seems to override that rudely :\

          Jim Klimov added a comment -

          So looking at the earlier screenshots of HTML source in this thread, the newer Badge plugin (1.10) did away with the in-lined style element, replacing it with a CSS class (or several, the badge-shortText group), which I could customize with a site-local CSS file.

          Badge 1.13 keeps the in-lined style removed, and also dropped the class.

          Actually gotta verify with some test code to make use of colored badges, per documented 

          /**
           * all params
           *
           * text: The text to add for this badge
           * background: (optional) The background-color for this short text
           * border: (optional) The border width for this short text
           * borderColor: (optional) The order color for this short text
           * color: (optional) The color for this short text
           * link: (optional) The link for this short text
           */
          addShortText(text: <text>, background: <background>,
                       border: <border>, borderColor: <borderColor>,
                       color: <color>, link: <link>) 

          I am not now convinced that these colors would be honoured :\

          Jim Klimov added a comment - So looking at the earlier screenshots of HTML source in this thread, the newer Badge plugin (1.10) did away with the in-lined style element, replacing it with a CSS class (or several, the badge-shortText group), which I could customize with a site-local CSS file. Badge 1.13 keeps the in-lined style removed, and also dropped the class. Actually gotta verify with some test code to make use of colored badges, per documented  /** * all params * * text: The text to add for this badge * background: (optional) The background-color for this short text * border: (optional) The border width for this short text * borderColor: (optional) The order color for this short text * color: (optional) The color for this short text * link: (optional) The link for this short text */ addShortText(text: <text>, background: <background>, border: <border>, borderColor: <borderColor>, color: <color>, link: <link>) I am not now convinced that these colors would be honoured :\

          Jim Klimov added a comment - - edited

          Here's a deployment with Badge 1.9.1 where I passed style-related parameters to `manager.addShortText()` (that might be the GPB plugin wrapper over Badge?) and got differently colored and bordered badges for some special cases (denoting the build cause, unstable and error reasons for easier human navigation in this summary):

          HTML design-wise, these arguments apparently went into the style of the span directly, and so the feature would likely be lost with Badge 1.10 and newer which keeps the style empty, if my guess is right:

          -------

          Comparing to Badge 1.10 which introduced CSS styles though, I think it makes sense for both plugins to extend the possible parameters with a new option (keeping legacy colors/borders intact) to set a CSS style name instead/additionally, with the Jenkins deployment free to define it in the custom CSS file. So instead of hard-coding numbers in my call, I'd tell addShortText to for example add a style="badge-error" to the list of styles for the entry (built-in ones being fallback for un-customized values). But that would be a separate feature, not directly about addressing the regression in this ticket. => JENKINS-73269

          Jim Klimov added a comment - - edited Here's a deployment with Badge 1.9.1 where I passed style-related parameters to `manager.addShortText()` (that might be the GPB plugin wrapper over Badge?) and got differently colored and bordered badges for some special cases (denoting the build cause, unstable and error reasons for easier human navigation in this summary): HTML design-wise, these arguments apparently went into the style of the span directly, and so the feature would likely be lost with Badge 1.10 and newer which keeps the style empty, if my guess is right: ------- Comparing to Badge 1.10 which introduced CSS styles though, I think it makes sense for both plugins to extend the possible parameters with a new option (keeping legacy colors/borders intact) to set a CSS style name instead/additionally, with the Jenkins deployment free to define it in the custom CSS file. So instead of hard-coding numbers in my call, I'd tell addShortText to for example add a style="badge-error" to the list of styles for the entry (built-in ones being fallback for un-customized values). But that would be a separate feature, not directly about addressing the regression in this ticket. => JENKINS-73269

            strangelookingnerd Daniel Krämer
            jimklimov Jim Klimov
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: