Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Fixed
-
Component/s: core
-
Labels:
-
Environment:2.0-alpha3
-
Similar Issues:
-
Epic Link:
Description
I'm not sure why this "feature" exists, but it appears the freestyle job configuration page is persisting the scroll state in a cookie. That by itself isn't the problem, but if you navigate away from the page after having scrolled to a tab, and then come back, the configuration page scrolls to the incorrect location.
Attachments
Issue Links
- links to
Activity
I thought I had fixed this, but will double check to see if it has been re-introduced.
gus reiber Haven't seen this is a while, so if the scroll is gone, that would be great and you can just resolve this.
Daniel Beck In checking this guy out I was able to catch the tab bar not pegged at the top of the screen doing the sort of back-n-forth testing you are describing. The issue is a similar root cause, scroll position faked out by browser's own state memory. So I have offered this PR: https://github.com/jenkinsci/jenkins/pull/2219
closing the issue, since Daniel isn't seeing it. I think I only saw a similar issue because Chrome was tripping over the debugger. Will check again when we open back up for 2.1
gus reiber The problem is that memory does not seem to behave in any way predictable. With shorter sections, you can never really know which section you're in. And the scrolling in the case of a short config form is also weird, as it doesn't even reach your previous section (too many sections on the screen). I mean, I knew of this feature in tabs, it was obvious it's still in there in scrolling, but I had no idea WTF it's doing. Imagine not knowing about it.