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

Build progress bar sometimes does not use full width

      Sometimes, the build progress bar does not take up the full width it is allocated, resulting in screenshots like https://github.com/jenkinsci/jenkins/pull/6562#issuecomment-1133440939 or https://gitter.im/jenkinsci/ux-sig?at=62912c2cef00bd1dc6011778

      janfaracik in https://gitter.im/jenkinsci/ux-sig?at=629157844e38f759e28ff91c proposes an issue with Bootstrap.

      Steps to reproduce

      1. Install Jenkins 2.350
      2. Install Warnings NG plugin 9.12.0 and its dependency bootstrap5-api 5.1.3-7
      3. Create a freestyle job
      4. Add a build step that sleeps for 20 seconds (e.g. shell sleep 20 )
      5. Add a post-build step that "Record compiler warnings and static analysis results", leave all options default
      6. Save
      7. Trigger 2 or more builds
      8. Wait a while

      Expected result

      Sane progress bar

      Actual result

      See attached

          [JENKINS-68670] Build progress bar sometimes does not use full width

          Daniel Beck added a comment -

          The affected page includes bootstrap-custom-build.css , indicating https://github.com/jenkinsci/bootstrap5-api-plugin/blob/d943170ed9fa95805670898346284eadceca0a7b/etc/bootstrap-custom-build.scss#L56 could be the culprit.

          Daniel Beck added a comment - The affected page includes bootstrap-custom-build.css , indicating https://github.com/jenkinsci/bootstrap5-api-plugin/blob/d943170ed9fa95805670898346284eadceca0a7b/etc/bootstrap-custom-build.scss#L56 could be the culprit.

          Basil Crow added a comment -

          How is "sane progress bar" defined? How is the actual result not sane? What commit introduced the problem? What release first contained the problematic commit? These are just some of the many things that need to be answered before this ticket can be considered "triaged".

          Basil Crow added a comment - How is "sane progress bar" defined? How is the actual result not sane? What commit introduced the problem? What release first contained the problematic commit? These are just some of the many things that need to be answered before this ticket can be considered "triaged".

          Daniel Beck added a comment -

          How is "sane progress bar" defined?

          A progress bar that's not broken.

          How is the actual result not sane? 

          The actual bar is a fraction of the total width and changes size inside the fixed width container.

          What commit introduced the problem? What release first contained the problematic commit?

          n/a, this is why I removed the regression label.

          Daniel Beck added a comment - How is "sane progress bar" defined? A progress bar that's not broken. How is the actual result not sane?  The actual bar is a fraction of the total width and changes size inside the fixed width container. What commit introduced the problem? What release first contained the problematic commit? n/a, this is why I removed the regression label.

          Basil Crow added a comment -

          I agree that the current progress bar is broken (for some definition of "broken") but my point is that a precise description of the problem will help motivate a precise and targeted fix/solution. Describing how "the actual bar is a fraction of the total width and changes size inside the fixed width container" helps to clarify this. Reversing that into problem statement, the problem could be defined as

          The progress bar is a fraction of the available width, which makes it difficult to estimate actual progress because such an estimation requires the mental mathematics of multiplying the visible progress by the fraction of the width that the progress bar occupies (requiring users to perform fractional arithmetic is generally bad user experience). Additionally, the fact that the progress bar changes size inside a fixed width container is both inconsistent and requires redoing the above mental arithmetic when the window is resized, further harming the user experience.

          One might think this type of thing should be "obvious", but if it were - this ticket wouldn't be open, would it? So making it explicit helps.

          n/a, this is why I removed the regression label.

          +1

          Basil Crow added a comment - I agree that the current progress bar is broken (for some definition of "broken") but my point is that a precise description of the problem will help motivate a precise and targeted fix/solution. Describing how "the actual bar is a fraction of the total width and changes size inside the fixed width container" helps to clarify this. Reversing that into problem statement, the problem could be defined as The progress bar is a fraction of the available width, which makes it difficult to estimate actual progress because such an estimation requires the mental mathematics of multiplying the visible progress by the fraction of the width that the progress bar occupies (requiring users to perform fractional arithmetic is generally bad user experience). Additionally, the fact that the progress bar changes size inside a fixed width container is both inconsistent and requires redoing the above mental arithmetic when the window is resized, further harming the user experience. One might think this type of thing should be "obvious", but if it were - this ticket wouldn't be open, would it? So making it explicit helps. n/a, this is why I removed the regression label. +1

          Ulli Hafner added a comment -

          I think a simple fix would be to remove the progress component from bootstrap since we have our own in Jenkins. 

          Ulli Hafner added a comment - I think a simple fix would be to remove the progress component from bootstrap since we have our own in Jenkins. 

          yokeshwaran added a comment -

           

          I like to work on this issue. I will try to reproduce the issue locally and then look into a potential fix. CC: danielbeck Beck, basil Crow, drulli 

          yokeshwaran added a comment -   I like to work on this issue. I will try to reproduce the issue locally and then look into a potential fix. CC: danielbeck Beck, basil Crow, drulli  

          Ulli Hafner added a comment -

          Please go ahead! A simple fix would be a pull request for the bootstrap 5 plugin that removes the progress.

          Ulli Hafner added a comment - Please go ahead! A simple fix would be a pull request for the bootstrap 5 plugin that removes the progress.

          yokeshwaran added a comment -

          Thanks, Ulli Hafner. I will work on the suggested fix and keep u updated.

          yokeshwaran added a comment - Thanks, Ulli Hafner. I will work on the suggested fix and keep u updated.

          yokeshwaran added a comment - - edited

          Hello everyone,

          While investigating the issue described in this ticket, I've observed that the problem of the progress bar not taking up its full width seems to be resolved in the latest version. But, I see a related but new behavior: as a job progresses, the entire length of the progress bar shrinks, deviating from its original length(Attached screenshot)

          A few points I noted:

          1. A change made by drulli  to etc/bootstrap-custom-build.scss file   https://github.com/jenkinsci/bootstrap5-api-plugin/commit/a8efc6e39db5714f3a5267b7136eaf2872bdeef6 , specifically the removal of the bootstrap progress component, inclusion of the variables-dark. Its possible that these changes might have had these effects on the progress bar behavior though this requires further investigation.
          2. The new behaviour I observed might not be directly related to the original issue, but it still has the functionality, appearance of the progress bar.

          I'm thinking creating a new ticket to address this new behaviour separately. Before I proceed, does anyone have suggestions related to this? Plus, has anyone observed this shrinking behavior of the progress bar in the latest version?

          yokeshwaran added a comment - - edited Hello everyone, While investigating the issue described in this ticket, I've observed that the problem of the progress bar not taking up its full width seems to be resolved in the latest version. But, I see a related but new behavior: as a job progresses, the entire length of the progress bar shrinks, deviating from its original length(Attached screenshot) A few points I noted: A change made by drulli   to etc/bootstrap-custom-build.scss file   https://github.com/jenkinsci/bootstrap5-api-plugin/commit/a8efc6e39db5714f3a5267b7136eaf2872bdeef6 , specifically the removal of the bootstrap progress component, inclusion of the variables-dark. Its possible that these changes might have had these effects on the progress bar behavior though this requires further investigation. The new behaviour I observed might not be directly related to the original issue, but it still has the functionality, appearance of the progress bar. I'm thinking creating a new ticket to address this new behaviour separately. Before I proceed, does anyone have suggestions related to this? Plus, has anyone observed this shrinking behavior of the progress bar in the latest version?

          Ulli Hafner added a comment -

          yokeshwaranvk thanks for looking into it. I must admit that I totally forgot that I removed the progress bar while fixing some dark theme issues, sorry about that. I think we can close this issue and create another one that describes the other observation that you made.

          Ulli Hafner added a comment - yokeshwaranvk thanks for looking into it. I must admit that I totally forgot that I removed the progress bar while fixing some dark theme issues, sorry about that. I think we can close this issue and create another one that describes the other observation that you made.

            yokeshwaranvk yokeshwaran
            danielbeck Daniel Beck
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: