Scrolling issue since beta.15

[pklaschka]

Have you read the Contributing Guidelines on issues?

• I have 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

Since beta.15, there are issues when trying to scroll through a docs page on Chrome on Windows (it seems weirdly specific; both Edge, i.e., Chromium, and Chrome in the same version on Linux don't have this issue).

When scrolling past a specific point (around 94px down the page), it "force-scrolls" you back to that point.

I believe I was able to track this down to 2f97a85: When I put a breakpoint in the Chrome debugger before the scrollIntoView, the issue doesn't happen (until I step over the breakpoint). When stepping over the breakpoint, it gets triggered several times (each time staggeringly scrolling further to the top) until I'm back at window.scrollY === 94.

This behavior doesn't occur on mobile layouts (i.e., in @media (max-width: 996px)).

Steps to reproduce

1. Open any beta.15-based project in Chrome 97.0.4692.99 (Official Build) (64-bit) on Windows 10
2. Go to a docs page that's long enough to scroll down
3. try scrolling down

Expected behavior

Scrolling should work "normally"

Actual behavior

It always jumps back to 94px when scrolling beyond that:

Tutorial.Intro._.Docs.Editor.-.Google.Chrome.-.2.February.2022.mp4

Your environment

• Public source code: n/a (every Docusaurus page using beta.15)
• Public site URL: n/a
• Docusaurus version used: 2.0.0-beta.15
• Environment name and version (e.g. Chrome 89, Node.js 16.4): Chrome 97.0.4692.99 (Official Build) (64-bit)
• Operating system and version (e.g. Ubuntu 20.04.2 LTS): Windows 10 Pro 21H2

Reproducible demo

https://stackblitz.com/edit/github-jepglu?file=package.json (just a starter beta.15 project)

Self-service

• I'd be willing to fix this bug myself.

[pklaschka]

I was also able to reproduce this in Chrome 98.0.4758.81 (Official Build) (64-bit) on the same OS. Firefox (96.0.3 (64-Bit)) and Edge (Version 97.0.1072.76 (Official build) (64-bit)) don't have this behavior.

[Josh-Cena]

Weird enough, this change has been made on the Docusaurus site for some time now, and pretty sure a bunch of Windows/chrome users have visited the website, yet you are the first to report this...

No Windows myself, so I had to use Browserstack to test this. There doesn't seem to be a problem with chrome 97.0.4692.71 + Windows 10 v1909, despite the horrible lagging because of remote connection.

[pklaschka]

@Josh-Cena Thanks for taking a look, and agreed: this is pretty weird.

I tried it in several different browser profiles (clearing cache, having no extensions, etc.) and consistently have this bug on Docusaurus pages (including, as I just realized after looking at your screen recording, docusaurus.io/docs) 🤔

If it turns out that, for whatever reason, I'm the only person experiencing this, I won't like it too much, but that knowledge will at least unblock me from upgrading to beta.15 (even though I'll then have to look at all Docusaurus docs in other browsers in the future) 😅 .

I'm not sure what else to say. I'm pretty sure it has something to do with the previously mentioned commit (which was a part of the beta.15 changes), so this might help to track this down, but other than that, I don't have anything more I can tell you. I'm also unable to reproduce on the same Chromium build on Linux, so this seems like some weird edge case.

I guess that either nobody else has this issue (which will be weird and a bit frustrating for me, but that knowledge still unblocks me), or somebody will "+1" this (in which case there might be more to it than some weird edge case on my end). Any of these results helps me, so let's see how this turns out 🤣 .

[Josh-Cena]

@cb0s since you 👍'd this, do you have follow-ups of the situation?

And... I did do some tests before merging that change because I knew it could be problematic for some browsers, but I never thought it could be this platform-specific 😄

[pklaschka]

@Josh-Cena @cb0s is on my team => that "+1" unfortunately doesn't count (he just also wants our docs to be unblocked 😀)

And... I did do some tests before merging that change because I knew it could be problematic for some browsers, but I never thought it could be this platform-specific 😄

I once played around with these APIs for another project and had a lot of weird edge cases => I could imagine this being the case here, as well, but of course, I can't be sure about that 🤔

[Josh-Cena]

@pklaschka Have you checked your browser extensions?

[pklaschka]

@pklaschka Have you checked your browser extensions?

Unfortunately so (I wish that could have been it, but unfortunately not) 😀 . I was able to reproduce this on Browser profiles with no extensions/modifications whatsoever, ones with extensions, etc. => no difference there (this seems to be rooted "deeper" in the browser)

[Josh-Cena]

Hmmm... Let's see if we can get other voices. I've asked in the Discord server and others can't reproduce this either 🤔

[pklaschka]

@Josh-Cena Thanks for your help 👍

[pklaschka]

@Josh-Cena I just had a quick idea to check the Chrome flags (since I had enabled Smooth Scrolling for an experiment a couple of weeks ago).

It turns out: chrome://flags/#enable-experimental-web-platform-features (the "Experimental Web Platform Features" flag) caused this (it had never caused me any trouble before => I never thought about disabling it 😅 .

Given that it is currently behind a flag, I'm now closing this issue (since it's probably up to just "being experimental" at the moment). But should this re-surface without the flag at any point in time (some currently experimental API becoming stable without this underlying issue getting fixed), let me state "for the record":
We now know which line (and version: 2.0.0-beta.15) probably introduced this unique and identifiable bug. It once worked in Chrome (after disabling the Experimental Web Platform Features Flag), so this might be a bug in Chrome if you experience this again.

[slorber]

@cassieevans also reported this recently, also due to Chrome exp feature flag

I think it's safe to ignore and assume it's a Chrome bug, hopefully they'll never release this bug or we won't be alone to complain 😅

[reeeeeee-dev]

Just had this happen to me in Firefox 97 on MacOS 11.6 (Big Sur). Started immediately after I upgraded from beta.8 to beta.15. Couldn't reproduce it in a fresh project though. Downgrading to beta.14 fixed it.

[Josh-Cena]

@reeeeeee-dev Do you have a repro? Have you customized your TOC? Is it reproducible cross-platform?

[AndreasGassmann]

I'm having exactly the same issue. I updated from 2.0.0-alpha.72 to 2.0.0-beta.15.

There is a weird build error when running npm run build that I'm still trying to track down, but npm run start works and loads the page, which then has the weird scrolling issue.

I'm using Brave browser (Version 1.34.80 Chromium: 97.0.4692.71 (Official Build) (arm64)), no special configurations or flags enabled.

One interesting thing, if you make the window narrower and the page goes into "mobile mode", it starts working flawlessly.

airgap-it/airgap-docs#30

[Josh-Cena]

@AndreasGassmann The auto-scrolling TOC feature is only on desktop, so mobile will always work. After you fixed your build error (which is because of the Node version being too low, not sure if there are more to come), I can inspect your site.

[AndreasGassmann]

I fixed the build issues.

A test version is deployed on netlify, you can see it on this page: https://aad5fc31ba1118975ab67fa94a41b6025f2b5782--airgap-docs-dev.netlify.app/guides/metamask

[pklaschka]

A test version is deployed on netlify, you can see it on this page: aad5fc31ba1118975ab67fa94a41b6025f2b5782--airgap-docs-dev.netlify.app/guides/metamask

I can reproduce it in the browser environment described above (without any flags, this time 😜 ), as well 🤔

[enigmalea]

I upgraded to beta.15, and am having the same issue in Opera (which is a chromium build) on the localhost version. FWIW I can visit the deployed version of the docusaurus.io page just fine, but the above test version provided by @AndreasGassmann deployed on netlify is doing the same thing.

EDIT: I just tried visiting the netlify example with all extensions disabled in incognito mode and the scrolling error still occurred.

[Josh-Cena]

@AndreasGassmann Your problem is the same as #6317 (comment). Your TOC is fixed with the container instead of being sticky at the top, which is bad UX anyways. And the cause is in src/pages/styles.module.css:

body > div {
  overflow: hidden;
}

Tag selectors can't be scoped; only class name selectors are. Therefore, this selector is global and affects the TOC as well. Removing this, or scoping this to your actual playground page, fixes the problem.

[Josh-Cena]

I feel like the auto-scrolling change is very good in that it successfully burns all the sites with accidentally bad design (fixed instead of sticky TOC)...

[AndreasGassmann]

Thanks, this solved my issue.

[Josh-Cena]

For anyone who lands here because of the page being "stuck" after upgrading to beta.15: your site probably wasn't working well already before that. In beta.14 and previous, your TOC is probably fixed in one place and scrolls with the rest of the page instead of being sticky at the top. It's bad UX and almost always relates to mistakes in your CSS. Look for places that may prevent the TOC from being sticky-positioned (e.g. overflow: hidden and align-items: baseline are very common ones) and fix these (e.g. by scoping to a particular class name).

[webprofusion-chrisc]

I would suggest this issue be re-opened. I can confirm this is a problem when using Chrome or MS Edge (98.x) on Windows (11) with "Experimental Web Platform features" enabled. I can confirm the main docusaurus site is affected and I can also assert that the problem exists even without any custom css (at least using preset-classic).

While this seems like it's not a problem in docusaurus, clearly something did change between docusaurus versions (not a problem in 2.0.0-beta.13).

We can obviously just all disable "Experimental Web Platform features", however the problem will reach epic proportions when whichever feature causing this is no longer experimental in Chrome. The point of the experimental flags are to surface issues.

[Josh-Cena]

While this seems like it's not a problem in docusaurus, clearly something did change between docusaurus versions (not a problem in 2.0.0-beta.13).

Yes, because in beta.15 we had an auto-scrolling TOC that uses JavaScript to scroll the TOC container.

The point of the experimental flags are to surface issues.

Not only to surface issues in incompatible websites, but in Chrome itself as well. We're not sure which side this bug is coming from. Until we get a response from the Chrome team (who unfortunately doesn't respond to bug reports very often) we may never know.

[slorber]

We can keep it closed.

If Chrome ever land this in non-experimental Chrome, we'll be reactive to fix it asap.

Until then, browsers adding new features are not supposed to break existing websites. The web is supposed to keep being retrocompatible. Hopefully, other websites will be affected as well and pressure the Chrome team to fix this.

[Josh-Cena]

We're fixing some of the actual issues (namely, #6620) in #6666, but I've tested and confirmed that the "Experimental Web Platform features" is still breaking the site. Not sure if anyone else has reported, but I've also sent a bug report to chrome. Let's see if they are able to get it fixed.