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

Running build logs have a different font size than finished build logs

    XMLWordPrintable

Details

    • 2.338

    Attachments

      Activity

        danielbeck Daniel Beck added a comment - - edited

        While the additional nested element existed in Jenkins 2.225, the font size was the same. It is different in 2.226, indicating https://github.com/jenkinsci/jenkins/commit/56bce19cd6e26a4e122f761cb6fd3baf47a870e1 caused this to break.

        Perhaps fqueiruga knows enough about the progressiveText insanity to safely get rid of the extra level of nesting?

        danielbeck Daniel Beck added a comment - - edited While the additional nested element existed in Jenkins 2.225, the font size was the same. It is different in 2.226, indicating https://github.com/jenkinsci/jenkins/commit/56bce19cd6e26a4e122f761cb6fd3baf47a870e1 caused this to break. Perhaps fqueiruga knows enough about the progressiveText insanity to safely get rid of the extra level of nesting?
        danielbeck Daniel Beck added a comment -

        I cannot manage to upload the other screenshot, Jira errors out. It looks pretty much like this one, just different font size

        danielbeck Daniel Beck added a comment - I cannot manage to upload the other screenshot, Jira errors out. It looks pretty much like this one, just different font size

        Homogeinizing the font sizes was tough, especially when dealing with monospaced elements, such as <pre>. This one probably slipped. Probably a missing rule somewhere.

        fqueiruga Félix Queiruga Balado added a comment - Homogeinizing the font sizes was tough, especially when dealing with monospaced elements, such as <pre>. This one probably slipped. Probably a missing rule somewhere.
        danielbeck Daniel Beck added a comment -

        fqueiruga Looks at the screenshot, there are two nested pre in a running build. This only applies to running builds.

        This didn't matter until 2.226, when you defined font-size: 0.95em; for pre, so each nested pre reduces font size by 5%.

        danielbeck Daniel Beck added a comment - fqueiruga Looks at the screenshot, there are two nested  pre in a running build. This only applies to running builds. This didn't matter until 2.226, when you defined font-size: 0.95em; for pre , so each nested pre reduces font size by 5%.

        then maybe the solution can be something like 

         pre pre { font-size: 1em; }
        fqueiruga Félix Queiruga Balado added a comment - then maybe the solution can be something like  pre pre { font-size: 1em; }
        danielbeck Daniel Beck added a comment -

        Sure, or even pre#out.console-output pre but that's just a workaround.

        The real problem IMO is the additional level of nesting that doesn't seem correct; but id didn't have a visual impact before your style changes. This is the reason I suggest we fix progressiveText.jelly possibly by just ripping out the IE workaround.

        danielbeck Daniel Beck added a comment - Sure, or even pre#out.console-output pre but that's just a workaround. The real problem IMO is the additional level of nesting that doesn't seem correct; but id didn't have a visual impact before your style changes. This is the reason I suggest we fix progressiveText.jelly possibly by just ripping out the IE workaround.

        I am not able to dedicate some time to it right now so I wasn't able to dig deeper into the jelly stuff. That said, the parent rule for 0.95 still needs to be there, in order for <pre> elements to not look broken in other contexts.

        fqueiruga Félix Queiruga Balado added a comment - I am not able to dedicate some time to it right now so I wasn't able to dig deeper into the jelly stuff. That said, the parent rule for 0.95 still needs to be there, in order for <pre> elements to not look broken in other contexts.
        danielbeck Daniel Beck added a comment -

        This is now extremely evident thanks to the recent redesign. Even with a "split" build log, which seems unintentional.

        CC janfaracik  timja

        danielbeck Daniel Beck added a comment - This is now extremely evident thanks to the recent redesign. Even with a "split" build log, which seems unintentional. CC janfaracik   timja

        People

          notmyfault Alexander Brandes
          danielbeck Daniel Beck
          Votes:
          0 Vote for this issue
          Watchers:
          3 Start watching this issue

          Dates

            Created:
            Updated:
            Resolved: