Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add action auto-scroll #30057

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

bytedream
Copy link

@bytedream bytedream commented Mar 25, 2024

Adds an auto-scroll/follow feature to running actions (#25186, #28535).

When new log lines are appended and the bottom of the logs container (.action-view-right) is visible at this time, the page automatically scrolls down to the bottom of the logs.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Mar 25, 2024
@pull-request-size pull-request-size bot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label Mar 25, 2024
@silverwind
Copy link
Member

silverwind commented Mar 25, 2024

This kind of scrolling while nice, does present a UX issue when the user scrolls up: It would scroll it down again when the next line is received which is disruptive. It would be better to:

  • Scroll down as long as the user has not manually scrolled
  • If the user has manually scrolled and is not at the end, don't scroll
  • If the user has manually scrolled and is at the end, scroll

That way, a user can to view lines in a running step, while still having autoscrolling when they scroll to bottom. This is how pretty much all terminals do it as well.

In case it's unclear how to do this, I may have some code snippets laying around somewhere.

Co-authored-by: silverwind <me@silverwind.io>
@bytedream
Copy link
Author

I try to comply to this behavior by only scrolling if the bottom of the container which contains all job steps is visible when new lines are added. So if the user scrolls up and the container bottom isn't visible, it won't continue scrolling.
This was the solution with the fewest code changes I came up with, but I'm also fine with the behavior you suggested.

@silverwind
Copy link
Member

Sounds good. I guess this case is a bit tricker than the ones I had because it's not a simple self-contained element that scrolls but the whole page. When in doubt, check how GitHub does it.

@bytedream
Copy link
Author

GitHub has the same behavior as my PR as long as there are only a few steps (+ the scroll down when visiting the an action page).
When an action has many steps which may exceed the screen height, GitHub keeps the logs around the middle of the screen, if the following to-be-executed job steps are still exceeding the remaining screen height. When manually scrolling further down so that the latest log line is in the upper half of the screen (or completely out of view), GitHub scrolls up again to keep the latest logs in the middle of the screen.
For example, Rust has actions with many steps.

From how GitHub does it, how you suggested it and how I would like it, I purpose the following:

  • Scroll down as long as the user has not manually scrolled
  • When the user has manually scrolled, keep following the logs when the last log line is in the bottom half of the screen, else do not follow

@lunny lunny added this to the 1.23.0 milestone May 5, 2024
@lunny lunny added the topic/ui Change the appearance of the Gitea UI label May 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. modifies/js size/S Denotes a PR that changes 10-29 lines, ignoring generated files. topic/ui Change the appearance of the Gitea UI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants