Page scroll position not reset to top on navigation (regression)

[geoffrich]

Describe the bug

When navigating to a new page, if you are already scrolled partway down the page, the next page load will keep the current scroll position and not scroll back to the top.

I believe this broke with next-193. When I install next-192, this does not happen -- navigating to a new page always scrolls to the top, just like regular browser navigation.

Reproduction

Init the SvelteKit demo project. Add the following paragraph in about.svelte after the last paragraph.

<p>Go <a href="/">home</a></p>

Make the browser window small enough so that the page scrolls and scroll to the bottom of the page. Click the Home link. The Home page loads, but does not scroll to the top (i.e. the nav bar is not visible).

.

Tested in Chrome and Firefox on Windows 10.

Logs

No response

System Info

System:
    OS: Linux 4.19 Ubuntu 20.04.1 LTS (Focal Fossa)
    CPU: (4) x64 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz
    Memory: 7.79 GB / 12.40 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 14.17.0 - ~/.nvm/versions/node/v14.17.0/bin/node
    Yarn: 1.22.5 - /usr/bin/yarn
    npm: 8.1.1 - ~/.nvm/versions/node/v14.17.0/bin/npm
  Browsers:
    Chrome: 89.0.4389.90
  npmPackages:
    @sveltejs/kit: ^1.0.0-next.193 => 1.0.0-next.193
    svelte: ^3.34.0 => 3.44.1

Severity

serious, but I can work around it

Additional Information

No response

[rmunn]

Almost certainly caused by something in https://github.com/sveltejs/kit/pull/2668, as that was merged in between the next.192 and next.193 releases and it's a scroll-related feature.

[raymclee]

I'm having same problem. What is the workaround please?

[geoffrich]

@raymclee for now, downgrade to 1.0.0-next.192. It's only 1 version back so you shouldn't be missing much (changelog)

npm i @sveltejs/[email protected]

[raymclee]

@raymclee for now, downgrade to 1.0.0-next.192. It's only 1 version back so you shouldn't be missing much (changelog)

npm i @sveltejs/[email protected]

thanks just tried. no problem with next.192!

[rosslh]

With 1.0.0-next.194 this is resolved on Chrome but it is still broken for me on Firefox

[bluwy]

@rosslh I'm not able to reproduce in Firefox with the repro steps given in this issue. Do you have a different repro for the issue?

[jgrieger]

@bluwy @rosslh With v1.0.0-next.199 it is still not working correctly for me on Firefox (94.0 Linux Mint and 94.1.2 Android 12). I can reproduce it by simply navigating back and forth via links on the footer. Worth noting: I toggle between two non-root pages, links to the "/" route always work.

[bluwy]

@jgrieger We haven't changed much in the router since this fix, so I'm guessing the root issue is the same as #2794 (newer). I haven't found a way around it yet.

[rosslh]

My issue was resolved at some point, not sure which version.

[josh-collinsworth]

Fixed for me in @sveltejs/[email protected].

[jgrieger]

Solve for me with @sveltejs/[email protected] :+1:.

[andreasnuesslein]

i still have this issue with @sveltejs/[email protected]

[sbutler-gh]

I've been having this issue recently in @sveltejs/[email protected] on MacOS / Chromium browser. Rolling back to npm i @sveltejs/[email protected] solved it for me for now (thanks @geoffrich )

[johnknoop]

Will this be resolved in an upcoming release? It's not a huge problem for me so I'd rather not downgrade to an earlier version, but it is a bit ugly so it would be great if it was solved a some point.

[akkie]

I have the same issue on MacOs with 1.0.0-next.240 on all available browsers. @benmccann please can we reopen this bug. I have seen that there are some related issues which are already closed. I'm not sure it makes sense to create a new bug every time this problem seems to be fixed.

[jose-manuel-silva]

Having the same issue on MacOs with SvelteKit v1.0.0-next.232

[nhe23]

I cannot reproduce this issue. Scroll position is reset to the top as it should be for me. Im also using MacOS and the current SvelteKit Version (v1.0.0-next.242) and tested with Chrome and Safari using links to different routes (explicitly not "/"). It would be great if someone who has this issue could provide a repository to reproduce and detailed system information.

[johnknoop]

I can only reproduce it on my iPhone, not on my laptop (Windows).

If you have an iPhone, try and visit my site and scroll down a bit, then use the hamburger menu to go to the page "Skapa konto" (means "create account" in Swedish). You'll find that the scroll position isn't reset, since you can scroll up a bit.

[jose-manuel-silva]

A little bit more info: I just updated to SvelteKit v1.0.0-next.245, and scroll is still not reseting on page change, tried it on firefox, brave, and safari, which are all updated. You can as well visit my website to see it not working [https://painhas.com], just go there, scroll down a bit, and click in "originals" on the header (for example). Also im on macOS Monterey 12.2 beta to be more specific.

[bluwy]

It's very hard to debug the issue with just links to a website. It would be great to have a minimal repro (either a github repo or stackblitz link) so we can track this down.

Currently, the code to scroll to top is here. The if (this.autoscroll) check is based on whether you've called disableScrollHandling().

In my tests of the https://painhas.com website, I can confirm that Kit is calling scrollTo(0, 0), which should scroll to the top. By injecting this code in the console:

const _scroll = window.scrollTo
window.scrollTo = function() {
  console.log('scrollTo', arguments)
  _scroll.apply(window, arguments)
}

[akkie]

Here is an example: https://github.com/akkie/svelte-scroll-issue

Steps to reproduce:

• yarn run dev
• open http://localhost:3000
• Scroll to bottom
• Click Log in

Sometimes on the first reload the scroll to top works. In this case scroll to bottom and click on another side.

[nhe23]

I can reproduce this issue with the given repository. The native scrollTo function that is used to scroll to the top does not work if the rootElement in the __layout.svelte has overflow: auto; and max-height: 100vh;. In the repository @akkie provided it is caused by the 'Drawer' component. So something like this:

<div style="max-height: 100vh; overflow-y: auto;">
	<main>
		<slot />
	</main>
	<Footer />
</div>

in the _layout.svelte prevents the native scrollTo function to work properly (https://stackoverflow.com/questions/1174863/javascript-scrollto-method-does-nothing)

However I'm not quite sure if SvelteKit can do anything about that as this issue is caused by CSS inside the SvelteKit App.

[jgrieger]

Maybe sveltekit as a cool tool could emit a warning if someone uses scrollTo() and has the given styles applied in the root component. :-)

[johnknoop]

@nhe23 in my case I don't have any such max-height so maybe that isn't the only thing that causes the failure to reset scroll?

[benmccann]

@johnknoop can you provide code and instructions for reproducing? as stated earlier, it's hard to debug without the code

[johnknoop]

@benmccann sure! Can I message you privately somehow? I don't want to make my repo publicly available.

[nhe23]

@johnknoop maybe you can create a minimal repo with just the pages and components that are needed to reproduce the issue. This way you can leave the stuff out you don't want wo be publicly available and everyone can contribute to solve this issue.

[johnknoop]

Ok, I've created a small repo now that you can use: https://github.com/johnknoop/scrollbug

There are two says two reproduce the issue:

1 / Desktop

Browser: Chrome on Win 11 On the start page, scroll all the way down to the bottom and click on the link in the footer called "skapa konto". Expected result: the scroll position would be reset to the top of the page. Observed result: the scroll position is stuck at the bottom of the page.

2 / Mobile

Browser: iOS Safari On the start page, scroll down a bit and click the green button that says "Starta nu".. Expected result: the scroll position would be reset to the top of the page. Observer result: the scroll position is ~100px or so from the top, just enough for the <h1> to be visible in the viewport (not sure if this is by design).

[johnknoop]

Here's a screen recording of the desktop version of the issue. Not sure if it may be caused by the fact that I have scroll-behavior: smooth on my site? That shouldn't be a factor on iOS Safari though, since smooth scrolling isn't supported by that browser.

[nhe23]

Thank you @johnknoop for creating a repo. Unfortunately I have some issues with it (using SvelteKit 1.0.0-next.250): 1.

2. $page.path has been replaced by $page.url.pathname ... you're probably using an older version of SvelteKit locally as this change was made a few weeks ago.

However I can see the issue on your site hublin.se using Chrome on MacOS. If I disable scroll-behavior: smooth for html and body in the DevTools it works. Your site is probably on SvelteKit 1.0.0-next.201. Have you tried the current version yet?