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

Help buttons choose wrong help area to show help in (regression in 2.264)

    XMLWordPrintable

Details

    Description

      See attached screenshots of Git Publisher post-build step in 2.263.1 and 2.328. If there exists a tag list entry, clicking the help button for the general feature will open help inside the tag list entry in an unrelated help area. If there's no tag listed, the correct help area (below the empty list) will be used.

      This is a regression between 2.263.x and 2.277.x.

      Attachments

        1. 2.263.1.png
          2.263.1.png
          389 kB
        2. 2.328.png
          2.328.png
          298 kB
        3. rebuild-1.33-on-2.222.x.png
          rebuild-1.33-on-2.222.x.png
          272 kB
        4. Screenshot 2022-07-05 at 14.29.21.png
          Screenshot 2022-07-05 at 14.29.21.png
          70 kB

        Issue Links

          Activity

            mawinter69 Markus Winter added a comment - - edited

            this seems to happen whenever inside a f:entry that will render help is something repeatable that as well contains something that renders a help link

            A manual workaround is to add a f:helpArea inside the f:entry before a f:repeatable

            <f:entry title="Tags" field="tagsToPush>
              <f:helpArea/>
              <f:repeatable field="tagsToPush" add="${%Add Tag}">
              ...
              </f:repeatable>
            </f:entry>

            One could also think of a new parameter to f:entry telling to put the helpArea before the invokeBody

            That would make the help area appear before the add button and it would be also above the repeatable things which is not so bad I think

             

            The same bug is also visible in the email-ext plugin for the triggers

            mawinter69 Markus Winter added a comment - - edited this seems to happen whenever inside a f:entry that will render help is something repeatable that as well contains something that renders a help link A manual workaround is to add a f:helpArea inside the f:entry before a f:repeatable <f:entry title= "Tags" field="tagsToPush> <f:helpArea/> <f:repeatable field= "tagsToPush" add= "${%Add Tag}" > ... </f:repeatable> </f:entry> One could also think of a new parameter to f:entry telling to put the helpArea before the invokeBody That would make the help area appear before the add button and it would be also above the repeatable things which is not so bad I think   The same bug is also visible in the email-ext plugin for the triggers
            basil Basil Crow added a comment -

            mawinter69 Any chance you could bisect this down to the commit that introduced the regression?

            basil Basil Crow added a comment - mawinter69 Any chance you could bisect this down to the commit that introduced the regression?
            danielbeck Daniel Beck added a comment -

            Bisecting core, it seems https://github.com/jenkinsci/jenkins/commit/87b72f57c3 introduced the original reported problem.

            That said, Git Publisher perhaps was not an ideal example. On https://github.com/jenkinsci/jenkins/commit/3996862228, Git Publisher looks messed up in a different way: Help buttons are on the bottom left of the related block, rather than top right. My best guess is a change in git plugin since the original report. Unfortunately I forgot to specify the plugin version. Trying a few git plugin versions, 4.10.1 has the misplaced help button (but correctly located help area), and 4.4.4 on 3996862228 looks as in the 2.263.1 screenshot.

            Still, even with the rest of the UI being weird, 87b72 introduced the misplaced help area.

             

            danielbeck Daniel Beck added a comment - Bisecting core, it seems https://github.com/jenkinsci/jenkins/commit/87b72f57c3 introduced the original reported problem. That said, Git Publisher perhaps was not an ideal example. On https://github.com/jenkinsci/jenkins/commit/3996862228 , Git Publisher looks messed up in a different way: Help buttons are on the bottom left of the related block, rather than top right. My best guess is a change in git plugin since the original report. Unfortunately I forgot to specify the plugin version. Trying a few git plugin versions, 4.10.1 has the misplaced help button (but correctly located help area), and 4.4.4 on 3996862228 looks as in the 2.263.1 screenshot. Still, even with the rest of the UI being weird, 87b72 introduced the misplaced help area.  
            danielbeck Daniel Beck added a comment -

            Unsure whether it's the same thing, but I observed something similar with rebuild plugin. Attaching a screenshot I took when Jenkins was already down, so the error is expected. The position is the problem.

            danielbeck Daniel Beck added a comment - Unsure whether it's the same thing, but I observed something similar with rebuild plugin. Attaching a screenshot I took when Jenkins was already down, so the error is expected. The position is the problem.
            mawinter69 Markus Winter added a comment -

            Don't think so. The plugin does
             

            <f:entry field="autoRebuild" title="${%Rebuild options:}">
              <f:checkbox default="false" checked="${it.autoRebuild}"
                          title="${%Rebuild Without Asking For Parameters}"/>
            </f:entry>
            <f:entry field="rebuildDisabled">
              <f:checkbox default="false" checked="${it.rebuildDisbaled}"
                          title="${%Disable Rebuilding for this job}"/>
            </f:entry>

            So it correctly places the help after the checkbox I think.

            This seems to be not optimal. Probably using something like this might be better.

             <f:optionalBlock name="autoRebuild" title="${%Rebuild Without Asking For Parameters}" checked="${it.autoRebuild}" inline="true" />
             <f:optionalBlock name="rebuildDisabled" title="${%Disable Rebuilding for this job}" checked="${it.rebuildDisbaled}" inline="true" />

             
             

            mawinter69 Markus Winter added a comment - Don't think so. The plugin does   <f:entry field= "autoRebuild" title= "${%Rebuild options:}" > <f:checkbox default = " false " checked= "${it.autoRebuild}" title= "${%Rebuild Without Asking For Parameters}" /> </f:entry> <f:entry field= "rebuildDisabled" > <f:checkbox default = " false " checked= "${it.rebuildDisbaled}"   title= "${%Disable Rebuilding for this job}" /> </f:entry> So it correctly places the help after the checkbox I think. This seems to be not optimal. Probably using something like this might be better. <f:optionalBlock name= "autoRebuild" title= "${%Rebuild Without Asking For Parameters}" checked= "${it.autoRebuild}" inline= " true " /> <f:optionalBlock name= "rebuildDisabled" title= "${%Disable Rebuilding for this job}" checked= "${it.rebuildDisbaled}" inline= " true " />    
            danielbeck Daniel Beck added a comment -

            Right, it looks like the UI didn't migrate that well from tables-to-divs. Attaching a screenshot of rebuild 1.33 from 2.222.x how it looked then, that made more sense.

            danielbeck Daniel Beck added a comment - Right, it looks like the UI didn't migrate that well from tables-to-divs. Attaching a screenshot of rebuild 1.33 from 2.222.x how it looked then, that made more sense.

            People

              Unassigned Unassigned
              danielbeck Daniel Beck
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated: