[UX] Modernize Back to Top button in Console Output

[hharshhsaini]

Fixes #26111

This pull request modernizes the Console Output navigation experience by introducing a floating, accessible “Back to Top” button.
Long build logs currently require excessive manual scrolling; this change adds a standard UX pattern that appears dynamically and allows users to smoothly return to the top of the page without disrupting log rendering.

---

Testing done

• Tested locally using mvn -pl war jetty:run -Dskip.yarn and yarn start
• Verified behavior on long console logs (>500 lines)
• Confirmed dynamic visibility when scrolling past threshold
• Verified smooth scroll behavior
• Tested keyboard navigation (Tab + Enter/Space)
• Tested on Chrome and Firefox
• Ran yarn lint and mvn spotless:apply successfully

---

Screenshots (UI changes only)

Before

before.mov

After

after.mov

video presentation-

up-button.mp4

---

Proposed changelog entries

• Add a floating “Back to Top” button to console output for easier navigation of long logs

---

Proposed changelog category

/label rfe, web-ui

---

Proposed upgrade guidelines

N/A

---

Submitter checklist

• The issue is well-described and linked.
• The changelog entry is appropriate for users and written in the imperative mood.
• Manual testing performed and described (UI-only change).
• No new public APIs were added.
• No deprecations were introduced.
• JavaScript is external and CSP-safe (no inline JS, no eval).
• No new dependencies were introduced.

---

---

Maintainer checklist

• There are at least two (2) approvals for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title.
• If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

Desired reviewers

@jenkinsci/core-pr-reviewers

[MarkEWaite]

The "before" and "after" screenshots are not visible in my view of the pull request. Can you upload them again?

[MarkEWaite]

Please restore the maintainers checklist to the pull request description. You seem to have dropped it.

[Copilot]

Pull request overview

This pull request modernizes the Console Output page by adding a floating "Back to Top" button that appears when scrolling beyond 300px, providing easier navigation for long build logs without disrupting the console output rendering.

Changes:

• Added SCSS styling for a circular, fixed-position button with smooth animations
• Implemented scroll-based visibility toggle using requestAnimationFrame for performance
• Integrated the component into the main app initialization and console page template

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
src/main/scss/components/_index.scss	Imports the new back-to-top component styles
src/main/scss/components/_back-to-top.scss	Defines styles for the floating button with transitions and hover states
src/main/js/components/back-to-top/index.js	Implements scroll detection and smooth scroll behavior
src/main/js/app.js	Initializes the back-to-top component on page load
core/src/main/resources/hudson/model/Run/console.jelly	Adds the button markup with aria-label for accessibility

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[hharshhsaini]

The "before" and "after" screenshots are not visible in my view of the pull request. Can you upload them again?

yes sir @MarkEWaite there is issue from my side , upploading the screenshots.

[NotMyFault]

Doesn't that conflict with #26111 (comment) and if not, why should that be part of core?

[krisstern]

Hi, this proposed change is a UX one, so why is the desired review the core PR reviewers team?

[hharshhsaini]

@MarkEWaite apologies for the inconvenience. I was unable to attach the screenshots correctly, so I’ve uploaded a short screen recording instead. Please let me know if you would prefer screenshots and I will re-upload them.

[krisstern]

@MarkEWaite apologies for the inconvenience. I was unable to attach the screenshots correctly, so I’ve uploaded a short screen recording instead. Please let me know if you would prefer screenshots and I will re-upload them.

This is actually a huge red flag. Is the code in this PR LLM-generated then?

[hharshhsaini]

Doesn't that conflict with #26111 (comment) and if not, why should that be part of core?

Thanks for the question!

This change only affects the built-in Console Output page, which is rendered directly by Jenkins core (not a plugin), and it does not introduce any new feature or extension point. It’s a small, self-contained UX improvement to an existing core page, similar to other console UI tweaks already in core.

If maintainers feel this should live elsewhere or be implemented differently, I’m happy to adjust the approach based on your guidance. @NotMyFault

[hharshhsaini]

Hi, this proposed change is a UX one, so why is the desired review the core PR reviewers team?

Good point, thanks for flagging that.

I added core PR reviewers by default out of habit, but I agree this is primarily a UX/web-ui change. I’m happy to update the desired reviewers or wait for guidance on the preferred reviewers for this type of change.
@krisstern

[hharshhsaini]

@MarkEWaite apologies for the inconvenience. I was unable to attach the screenshots correctly, so I’ve uploaded a short screen recording instead. Please let me know if you would prefer screenshots and I will re-upload them.

This is actually a huge red flag. Is the code in this PR LLM-generated then?

@krisstern
Thanks for raising the concern, that’s fair to ask.

The code was written and tested by me locally; the issue with screenshots was purely a GitHub upload problem on my side (local path paste + edit conflicts), not related to how the code was produced. I’ve now uploaded a screen recording to make the behavior visible immediately.

If you prefer static screenshots instead, I can re-upload them again — just let me know. I’m happy to adjust based on reviewer preference.

[krisstern]

Hi, this proposed change is a UX one, so why is the desired review the core PR reviewers team?

Good point, thanks for flagging that.

I added core PR reviewers by default out of habit, but I agree this is primarily a UX/web-ui change. I’m happy to update the desired reviewers or wait for guidance on the preferred reviewers for this type of change. @krisstern

I have already made the appropriate choice of reviewers accordingly, in case you have not yet noticed.

[krisstern]

If you prefer static screenshots instead, I can re-upload them again — just let me know. I’m happy to adjust based on reviewer preference.

In case you have not noticed, there is a "Paste, drop, or click add files" button on GitHub at the bottom of each comment you can use to upload images, so you do not need to do that manually.

[hharshhsaini]

[krisstern]

You images are private for some reason, like with link https://private-user-images.githubusercontent.com/218725159/538794840-d8b80a9e-443e-405f-a25d-5dea5572a189.JPG for the before image. Is there any reason why this is the case?

[hharshhsaini]

If you prefer static screenshots instead, I can re-upload them again — just let me know. I’m happy to adjust based on reviewer preference.

In case you have not noticed, there is a "Paste, drop, or click add files" button on GitHub at the bottom of each comment you can use to upload images, so you do not need to do that manually.

Thanks for the clarification, and sorry about the back-and-forth.

I’m still having trouble uploading images via the UI on my side, so I’ve kept the short screen recording for now to show the behavior. I’ll re-upload static screenshots as soon as I’m able to resolve the upload issue, since I understand that’s preferred for review.

[hharshhsaini]

You images are private for some reason, like with link https://private-user-images.githubusercontent.com/218725159/538794840-d8b80a9e-443e-405f-a25d-5dea5572a189.JPG for the before image. Is there any reason why this is the case?

Thanks for checking and sorry for the trouble here.

I’ve tried uploading the screenshots both in the PR description and in comments, but GitHub keeps turning them into private links on my side. I’m not sure why that’s happening, but I don’t want to block review on this.

For now, the short screen recording shows the full behavior end-to-end. As soon as I’m able to resolve the GitHub upload issue, I’ll replace it with static screenshots, since I understand those are preferred.

[hharshhsaini]

Please restore the maintainers checklist to the pull request description. You seem to have dropped it.

@MarkEWaite thanks for pointing that out , the maintainer checklist has been restored in the PR description now.

[janfaracik]

Haven't looked at implementation yet, but this is probably something that we could reuse across core/plugins if we wanted - e.g. Pipeline Graph View.

Any thoughts on making it a property of layout.jelly so that other pages can use it?

[krisstern]

Haven't looked at implementation yet, but this is probably something that we could reuse across core/plugins if we wanted - e.g. Pipeline Graph View.

Any thoughts on making it a property of layout.jelly so that other pages can use it?

I actually like the idea

[timja]

either that or a tag that can be added

[janfaracik]

either that or a tag that can be added

Yeah a tag probably makes more sense, probably want to keep layout.jelly as simple as possible.

[hharshhsaini]

Thanks @krisstern @timja @janfaracik , that makes sense.

I agree that this could be useful beyond the console page (Pipeline Graph View is a good example) and I like the idea of making it reusable.

A dedicated tag/helper sounds cleaner than adding more responsibility to layout.jelly especially to keep layout.jelly simple as mentioned.

I’m happy to refactor the current implementation in that direction if that’s the preferred approach. just leme know what shape you’d like (e.g a Jelly tag, reusable fragment, or other pattern you prefer in core).

[krisstern]

@hharshhsaini looks like the team has settled on the tag approach. You may want to shift your focus to that and make changes accordingly in this PR to continue the work.

[hharshhsaini]

@hharshhsaini looks like the team has settled on the tag approach. You may want to shift your focus to that and make changes accordingly in this PR to continue the work.

@krisstern thanks for the clarification

I’ll refactor the current implementation to use a reusable tag-based approach so it can be adopted by other pages (like Pipeline Graph View) in the future. I ll update this PR accordingly and follow up once the changes are ready for review.

[hharshhsaini]

@janfaracik @timja @krisstern thanks for the guidance , I have refactored the implementation to a reusable Jelly tag as suggested .

The 'Back to Top' button now lives in a dedicated layout tag ('<l:backToTop />'), so it can be reused by other pages or plugins without tying it to the console view. The console page has been updated to use the tag, and the behavior/UI remains unchanged (same threshold, styling, smooth scroll, etc.).

I also moved the i18n string into a tag-specific properties file and cleaned up the now-unused console entry.

Please let me know if this looks like the right direction or if you’d like any adjustments to the tag structure or placement.

[hharshhsaini]

@timja sir please have a look over my work.

[daniel-beck]

@hharshhsaini Please be patient. Any pings in under a week if an issue isn't urgent are unnecessarily pushy.

[hharshhsaini]

@hharshhsaini Please be patient. Any pings in under a week if an issue isn't urgent are unnecessarily pushy.

yes sir undrstanding this, will care of this next time.

[hharshhsaini]

@krisstern sir should I work on another issue or wait until this PR is merged.

[krisstern]

@hharshhsaini yes, you may work on a new issue while you await feedback from this one

[hharshhsaini]

@krisstern waiting for the feedback sir .

[hharshhsaini]

@daniel-beck sir waiting for the feedback , please have a look on my work .