Disable autoscroll button improvement

Description

Remove the disable autoscroll button in the pipeline page, it is useless (at least in my opinion).

Proposal

I think the right way for it to work is the following:

1. Auto scroll should be enabled by default
2. If a user scrolls up -> disable autoscroll
3. If a user scroll back to end end -> enable autoscroll again

\cc @jschatz1

Added ~19173 frontend labels

/cc @dimitrieh

rewriting my replies

@jbamaro I think you are talking about the build view, not?

Auto scroll should be enabled by default

This is the feature, which I don't think should be like that. I don't expect my view to move automatically without my consent. Say that I open up a few builds in a few new tabs.. I would first want to know which build it is when I finally open it up. Although I do agree I am mainly interested in how the build log is progressing or has progressed.

@markpundsack What do you think?

What I think would be nice perhaps is a timercountdown that happens when a user views the build in the new tab. It then counts down until the auto scroll kicks in , after which it will smoothly scroll down towards the end of the build log and enabled auto scoll if the build is still progressing.

If a user scrolls up -> disable autoscroll

Yes! This should be like this!

If a user scroll back to end end -> enable autoscroll again

Yes, a good suggestion as well!

---

On a sidenote I think we should tinker around with the autoscroll buttons and "go to top" / "go to bottom" buttons anyway as they are quite ugly at the moment. The only related issue I could find was: https://gitlab.com/gitlab-org/gitlab-ce/issues/19058

@markglenfletcher do you perhaps know of any?

Added ~19492 and removed frontend labels

also this seem to be a bug.. when at the bottom these buttons disappear, even the one that wants to scroll to the top:

@dimitrieh Yep ! Build view was what I meant.

The timer would be nice, but only while the build is running, after it is done I see no advantage on showing the bottom of the log.

An that way developers can see the log like a terminal (what they are used to) without the need to click on a button

@dimitrieh Looks like it's covered in the following issue, making this a duplicate:

• Build log should scroll better - https://gitlab.com/gitlab-org/gitlab-ce/issues/19620

@dimitrieh you're overthinking it. :) the window doesn't scroll, just the log. No need for timer.

I've made this exact proposal before. ;) Can't look up the issue number right now.

@markpundsack I mentioned your original issue earlier ^^

I know of issue #21832 (closed) which is being resolved by @lbennett in !6270 (merged) and !6288 (merged) (merged).

@eservais Thanks for notifying me of this issue. I am indeed working on the UX of the build scroll (was in review but now merging some big conflicts) which will fix the buggy behaviour of the current setup, but it wont introduce any new functionality.

Related https://gitlab.com/gitlab-org/gitlab-ce/issues/19620

Mentioned in issue #24339 (closed)

Mentioned in issue #19620 (closed)

mentioned in issue #26109 (closed)

moved to gitlab#6546

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue