• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • core
    • OS: MacOS Mojave (10.14.6)
      JDK: 11.0.2
      JRE: 11.0.2+9-LTS
      Jenkins: 2.225
      Browsers: Chrome,Firefox,Safari
    • 2.226

      Recently noticed, whilst trying to diagnose another issue, that we are now unable to move/reorder items within a job.  

      Attempting to move/reorder items in the build or post-build  section results in the browser scrolling upwards with no ability to move item.  Tried on multiple browsers and computers.

      Steps to reproduce:

      1. Create a freestyle project
      2. Add multiple build steps
      3. Apply changes
      4. Reload the page (it only affects steps that were present when the page was loaded)
      5. Try to drag/drop build steps with the handle in the top left to change their order

      Expected result: It works

      Actual result: It doesn't

      Notes: The "placeholder" rectangle appears further up the page.

          [JENKINS-61429] Unable to move/reorder steps within a job

          Daniel Beck added a comment - - edited

          Confirmed. Only affects (post)build steps that have been there since before the page loaded.

          Daniel Beck added a comment - - edited Confirmed. Only affects (post)build steps that have been there since before the page loaded.

          Daniel Beck added a comment -

          Affects 2.222, too.

          Daniel Beck added a comment - Affects 2.222, too.

          Daniel Beck added a comment -

          Seems to have been broken in 2.217. 2.216 wasn't released, so "between 2.215 and 2.217".

          Daniel Beck added a comment - Seems to have been broken in 2.217. 2.216 wasn't released, so "between 2.215 and 2.217".

          Daniel Beck added a comment -

          fqueiruga Could you please take a look at this? Given https://github.com/jenkinsci/jenkins/compare/jenkins-2.215...jenkins-2.217 it's likely to be related to your JS rework.

          Daniel Beck added a comment - fqueiruga Could you please take a look at this? Given https://github.com/jenkinsci/jenkins/compare/jenkins-2.215...jenkins-2.217 it's likely to be related to your JS rework.

          Ill take a look

          Félix Queiruga Balado added a comment - Ill take a look

          Daniel Beck added a comment -

          I confirmed system config and view config are unaffected (and they use the pre-2.0 config page style).

          Daniel Beck added a comment - I confirmed system config and view config are unaffected (and they use the pre-2.0 config page style).

          Daniel Beck added a comment -

          Folders are affected too, and they use the 2.0 config page style, just like freestyle jobs.

          Daniel Beck added a comment - Folders are affected too, and they use the 2.0 config page style, just like freestyle jobs.

          Daniel Beck added a comment -

          A workaround would be to delete build steps and recreate them, as newly created steps can be reordered. That's only really feasible with simple build steps like shell/batch though, as they're basically one big textarea can can be copied easily into a new step.

          Daniel Beck added a comment - A workaround would be to delete build steps and recreate them, as newly created steps can be reordered. That's only really feasible with simple build steps like shell/batch though, as they're basically one big textarea can can be copied easily into a new step.

          I created a PR that fixes it. I'm doing some comprehensive manual testing to ensure everything is alright.

          Félix Queiruga Balado added a comment - I created a PR that fixes it. I'm doing some comprehensive manual testing to ensure everything is alright.

          I have a better idea of what caused this regression. I’ll try to explain it.

          The war/src/main/js/config-scrollspy.js JS entry point contains some fixes for drag & drop behaviour for the job and folders form forms. Fixes are applied on a proxied Behaviour.specify call on the tabbar.js file it imports. These fixes are initialized by a function wrapped within a $() jquery block .(https://github.com/jenkinsci/jenkins/blob/23ab517cb4de3edd80e07b77d332d47eb9049276/war/src/main/js/config-scrollspy.js#L29).

          Before 2.217, the code would run in the following order:

          1. config-scrollspy.js loads and it’s executed.
          2. The initialization code runs immediatly and the Behaviour.specify call registers the fixes (https://github.com/jenkinsci/jenkins/blob/1ca9f6e8d649be88adb364da5dc2533706a8bfa5/war/src/main/js/widgets/config/tabbar.js#L13)
          3. The window.onload event handler is triggered, and runs all pieces of code set up via Behaviour.specify

          On 2.217+:

          1. config-scrollspy.js loads and it’s script-level code is executed, but the initialization code does not run.
          2. The window.onload event handler is triggered, and runs all pieces of code set up via Behaviour.specify. Because the intialization code was not yet run on the config-scrollspy.js file, drag & drop widgets existing on the page are not initialized.
          3. The initialization code for the drag & drop fixes is run. Because it came after the _window.onload _event, it will only apply to draggable widgets added after this point (i.e. recently added and unsaved steps).

          Basically, jQuery will wait until window.onload event to run the subscription code on 2.217+. The fix consists on moving the Behaviour.specify call on the tabbar.js file to be run when the script loads, so that it happens before the window.onload event.

          I don’t think it will negatively impact any other part of the app / plugin.

          Félix Queiruga Balado added a comment - I have a better idea of what caused this regression. I’ll try to explain it. The war/src/main/js/config-scrollspy.js JS entry point contains some fixes for drag & drop behaviour for the job and folders form forms. Fixes are applied on a proxied Behaviour.specify call on the tabbar.js file it imports. These fixes are initialized by a function wrapped within a $() jquery block .( https://github.com/jenkinsci/jenkins/blob/23ab517cb4de3edd80e07b77d332d47eb9049276/war/src/main/js/config-scrollspy.js#L29 ). Before 2.217, the code would run in the following order: config-scrollspy.js loads and it’s executed. The initialization code runs immediatly and the Behaviour.specify call registers the fixes ( https://github.com/jenkinsci/jenkins/blob/1ca9f6e8d649be88adb364da5dc2533706a8bfa5/war/src/main/js/widgets/config/tabbar.js#L13 ) The window.onload event handler is triggered, and runs all pieces of code set up via Behaviour.specify On 2.217+: config-scrollspy.js loads and it’s script-level code is executed, but the initialization code does not run. The window.onload event handler is triggered, and runs all pieces of code set up via Behaviour.specify . Because the intialization code was not yet run on the config-scrollspy.js file, drag & drop widgets existing on the page are not initialized. The initialization code for the drag & drop fixes is run. Because it came after the _window.onload _event, it will only apply to draggable widgets added after this point (i.e. recently added and unsaved steps). Basically, jQuery will wait until window.onload event to run the subscription code on 2.217+. The fix consists on moving the Behaviour.specify call on the tabbar.js file to be run when the script loads, so that it happens before the window.onload event. I don’t think it will negatively impact any other part of the app / plugin.

            fqueiruga Félix Queiruga Balado
            andyh200 Andy H
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: