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

the backtotopbutton only shows when scrolling up slightly after scrolling down #10135

Open
5 of 7 tasks
homotechsual opened this issue May 13, 2024 · 5 comments · May be fixed by #10138
Open
5 of 7 tasks

the backtotopbutton only shows when scrolling up slightly after scrolling down #10135

homotechsual opened this issue May 13, 2024 · 5 comments · May be fixed by #10138
Labels
bug An error in the Docusaurus core causing instability or issues with its execution

Comments

@homotechsual
Copy link
Contributor

Have you read the Contributing Guidelines on issues?

Prerequisites

  • I'm using the latest version of Docusaurus.
  • I have tried the npm run clear or yarn clear command.
  • I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
  • I have tried creating a repro with https://new.docusaurus.io.
  • I have read the console error message carefully (if applicable).

Description

After scrolling down the back to top button doesn't show unless you scroll up slightly.

Reproducible demo

No response

Steps to reproduce

  1. Go to https://docusaurus.io/docs/next/api/themes/configuration
  2. Scroll down
  3. Scroll up slightly - note that the backtotopbutton appears.

Expected behavior

The button should appear once scrolling down past the threshold without the need to scroll up slightly.

Actual behavior

The button doesn't appear until you scroll up again slightly.

Your environment

  • Public source code:
  • Public site URL:
  • Docusaurus version used:
  • Environment name and version (e.g. Chrome 89, Node.js 16.4):
  • Operating system and version (e.g. Ubuntu 20.04.2 LTS):

Self-service

  • I'd be willing to fix this bug myself.
@homotechsual homotechsual added bug An error in the Docusaurus core causing instability or issues with its execution status: needs triage This issue has not been triaged by maintainers labels May 13, 2024
@Raj-Mandal-20 Raj-Mandal-20 linked a pull request May 14, 2024 that will close this issue
3 tasks
@slorber
Copy link
Collaborator

slorber commented May 16, 2024

@homotechsual It has been designed that way on purpose in #4912

I'm not against changing it but is it really an improvement considering the button is already quite useless and most modern docs solutions do not have one?

For example VuePress had it, and VitePress doesn't have it, probably because it's not that useful. Do we really want to distract the reading experience with a button that appears? Showing on scroll up is less likely to be distracting so I'm in favor of keeping the current behavior, although it may looks surprising.

@slorber slorber removed the status: needs triage This issue has not been triaged by maintainers label May 16, 2024
@homotechsual
Copy link
Contributor Author

There's a certain logic there. The current behaviour feels less discoverable and less intuitive for a user. I'd probably lean towards saying remove it altogether rather than have the current behaviour or make the behaviour (and presence altogether) configurable.

@slorber
Copy link
Collaborator

slorber commented May 16, 2024

The current behaviour feels less discoverable and less intuitive for a user.

If a user wants to scroll at the top, he has to scroll up. So, the way to go to the top would actually permit you to discover the feature 😄 .

Have people actually complained about it? Like they didn't know the feature existed or something?

Removing it could annoy some users. Making it configurable could feel a bit overkill. People that don't like this behavior can swizzle the theme component. If nobody swizzled it to implement another behavior, this is probably because the current behavior is not annoying enough for people to take action.

Has anyone in our whole community ever swizzled to disable the button, or change its scroll behavior? If that's the case, I'm more likely to add an option because there's proof the community would use it.

@homotechsual
Copy link
Contributor Author

The current behaviour feels less discoverable and less intuitive for a user.

If a user wants to scroll at the top, he has to scroll up. So, the way to go to the top would actually permit you to discover the feature 😄 .

Have people actually complained about it? Like they didn't know the feature existed or something?

Removing it could annoy some users. Making it configurable could feel a bit overkill. People that don't like this behavior can swizzle the theme component. If nobody swizzled it to implement another behavior, this is probably because the current behavior is not annoying enough for people to take action.

Has anyone in our whole community ever swizzled to disable the button, or change its scroll behavior? If that's the case, I'm more likely to add an option because there's proof the community would use it.

These are good questions. It's come up once so far on Discord (which is what prompted this issue) I'm not aware of other discussions - not that that is in and of itself a sign of anything other than I haven't seen them :-)

@slorber
Copy link
Collaborator

slorber commented May 16, 2024

Maybe before introducing an option, what we could do is to add that option to the theme-common hook first, so that people can apply the customization easily through swizzle?
And if we see people doing it in practice, then we add it to themeConfig?

What would be a good API (for both hook + themeConfig) to make this configurable?

type ScrollToTopConfig = {appearOn: "scroll" | "scroll-up", threshold: number} | null

???

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An error in the Docusaurus core causing instability or issues with its execution
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants