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

Unexpected scrolling on job configuration page

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: In Progress (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: core
    • Labels:
    • Environment:
      Build for 2.0 PR 2182 with #4603
    • Similar Issues:

      Description

      Steps to reproduce:

      • Install recommended plugins
      • Create a freestyle job named 'foo'
      • radiobutton 'Git'
      • Click 'Advanced…' to show Advanced Project Options
      • Check 'This build is parameterized'
      • Add two boolean parameters (no need to specify name or anything)
      • Check 'Retry Count'

      Expected result: Retry Count gets checked
      Actual result: It does get checked, but the page scrolls down.

        Attachments

          Activity

          Hide
          j4_james James Holderness added a comment -

          I encountered a similar problem on the management Configure System page, while clicking on a checkbox for an optional block. I eventually tracked down the issue to a bug in the scrollIntoView function in hudson-behaviour.js (see here). This seems a generic enough function that I could imagine it causing problems in other places too.

          The issue is that it's calculating the distance to move relative to the current scroll position, but it's obtaining the current scroll position from document.body.scrollTop which is always zero. It should be using document.documentElement.scrollTop (or possibly a combination of the two for backwards compatibility). Chrome used to support body.scrollTop, but that was a bug, and once that was fixed, anything that relied on the bug stopping working. You can read more about it in the Chromium issue tracker here and here.

          This can be a difficult issue to reproduce, because sometimes it appears to work. But that's just because of another bug in the updateOptionalBlock function, which often returns a lot of NaN coordinates for the block's visible region. The result being that it just doesn't scroll at all (which is at least better that jumping to the bottom of the page).

          Show
          j4_james James Holderness added a comment - I encountered a similar problem on the management Configure System page, while clicking on a checkbox for an optional block. I eventually tracked down the issue to a bug in the scrollIntoView function in hudson-behaviour.js (see here ). This seems a generic enough function that I could imagine it causing problems in other places too. The issue is that it's calculating the distance to move relative to the current scroll position, but it's obtaining the current scroll position from document.body.scrollTop which is always zero. It should be using document.documentElement.scrollTop (or possibly a combination of the two for backwards compatibility). Chrome used to support body.scrollTop , but that was a bug, and once that was fixed, anything that relied on the bug stopping working. You can read more about it in the Chromium issue tracker here and here . This can be a difficult issue to reproduce, because sometimes it appears to work. But that's just because of another bug in the updateOptionalBlock function, which often returns a lot of NaN coordinates for the block's visible region. The result being that it just doesn't scroll at all (which is at least better that jumping to the bottom of the page).
          Hide
          tlopespt Tiago Lopes added a comment -

          Still happening on 2.10, checking an optionalBlock with the property ' inline="true" ' is causing the page to scroll to the bottom on Firefox

          Show
          tlopespt Tiago Lopes added a comment - Still happening on 2.10, checking an optionalBlock with the property ' inline="true" ' is causing the page to scroll to the bottom on Firefox
          Hide
          danielbeck Daniel Beck added a comment -

          Reproduced on pristine 1.642.2 with same steps.

          Not a regression, and apparently rare serious enough for users not to complain in numbers, so let's leave this until after 2.0.

          Show
          danielbeck Daniel Beck added a comment - Reproduced on pristine 1.642.2 with same steps. Not a regression, and apparently rare serious enough for users not to complain in numbers, so let's leave this until after 2.0.
          Hide
          danielbeck Daniel Beck added a comment -

          gus reiber It's not useful to link to private Jenkins instances. Not even I know how to access that one (and for the purposes of this issue tracker, I don't want to know).

          Show
          danielbeck Daniel Beck added a comment - gus reiber It's not useful to link to private Jenkins instances. Not even I know how to access that one (and for the purposes of this issue tracker, I don't want to know).
          Hide
          gusreiber gus reiber added a comment -

          https://github.com/jenkinsci/jenkins/pull/2193

          I have offered a PR that fixes the issue specifically for v2, as I am not sure if it doesn't mostly work enough in v1 that people like it, despite being broken in some cases. I don't think it is worth fixing, but others might think so. Daniel Beck, do as you will....

          Show
          gusreiber gus reiber added a comment - https://github.com/jenkinsci/jenkins/pull/2193 I have offered a PR that fixes the issue specifically for v2, as I am not sure if it doesn't mostly work enough in v1 that people like it, despite being broken in some cases. I don't think it is worth fixing, but others might think so. Daniel Beck , do as you will....

            People

            • Assignee:
              gusreiber gus reiber
              Reporter:
              danielbeck Daniel Beck
            • Votes:
              1 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: