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

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

      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.

        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

          [JENKINS-67537] Help buttons choose wrong help area to show help in (regression in 2.264)

          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

          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 Crow added a comment -

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

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

          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.

           

          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.  

          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.

          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.

          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" />

           
           

          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 " />    

          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.

          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.

          Daniel Beck added a comment -

          The root cause of this issue appears to be the migration of the help button from the right column to next to the title label. As a result, the repeatable content is now after the help button, not before, so a search of the help area will find one inside the repeatable content.

          Daniel Beck added a comment - The root cause of this issue appears to be the migration of the help button from the right column to next to the title label. As a result, the repeatable content is now after the help button, not before, so a search of the help area will find one inside the repeatable content.

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

              Created:
              Updated: