• 339.v1edb_5e63da_45

      The embeddable build status plugin sets the font-family to Console, "Courier New", Courier, monospace somewhere, according to browser tools.

      This setting overwrites Jenkins' native fonts used, impacting components the embeddable build plugin shouldn't touch, as seen at the search bar font:

      https://ci.jenkins.io/job/Plugins/job/console-column-plugin/job/master/lastCompletedBuild/badge/

      The correct font layout can be seen on any other page that is not modified by the embeddable build status plugin:

          [JENKINS-70602] Don't overwrite system fonts

          Mark Waite added a comment -

          Nice catch! The embeddable build status plugin is using an "INPUT" field in a rather strange way. Each of the example items is an input field with a style sheet applied to the input field. The style sheet it is inserting on that page adjusts input fields which causes it to alter the style of the input that is used for the search bar.

          I think it should be changed to simple text with a copy icon to the right of the text. Then the style sheet entry that modifies input fields on that page can be removed.

          notmyfault you have much more experience with UI and layout than I do. Does that make sense to you? Is there possibly some other reason why the original implementation used an input field? The commit that added the style for the input field does not provide any further insights.

          Mark Waite added a comment - Nice catch! The embeddable build status plugin is using an "INPUT" field in a rather strange way. Each of the example items is an input field with a style sheet applied to the input field. The style sheet it is inserting on that page adjusts input fields which causes it to alter the style of the input that is used for the search bar. I think it should be changed to simple text with a copy icon to the right of the text. Then the style sheet entry that modifies input fields on that page can be removed. notmyfault you have much more experience with UI and layout than I do. Does that make sense to you? Is there possibly some other reason why the original implementation used an input field? The commit that added the style for the input field does not provide any further insights.

          Is there possibly some other reason why the original implementation used an input field?

          I would take a guess and assume this was considered a safe change back then, nobody noticed or reported anything odd. I proposed a PR to shift the fonts to the element they actually touch, rather having it on a high level.

          Alexander Brandes added a comment - Is there possibly some other reason why the original implementation used an input field? I would take a guess and assume this was considered a safe change back then, nobody noticed or reported anything odd. I proposed a PR to shift the fonts to the element they actually touch, rather having it on a high level.

            notmyfault Alexander Brandes
            notmyfault Alexander Brandes
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: