Clicking a Link does't scroll to top on the next page

[IonelLupu]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

$ next info

    Operating System:
      Platform: linux
      Arch: x64
      Version: Ubuntu 20.04.0 LTS Mon Jan 23 2023 17:53:48 GMT+0200 (Eastern European Standard Time)
    Binaries:
      Node: 16.14.2
      npm: 7.17.0
      Yarn: 1.22.19
      pnpm: 7.13.6
    Relevant packages:
      next: 13.1.4
      eslint-config-next: 13.1.4
      react: 18.2.0
      react-dom: 18.2.0

warn  - Latest canary version not detected, detected: "13.1.4", newest: "13.1.5-canary.2".
        Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
        Read more - https://nextjs.org/docs/messages/opening-an-issue

Which area(s) of Next.js are affected? (leave empty if unsure)

App directory (appDir: true), Routing (next/router, next/navigation, next/link)

Link to the code that reproduces this issue

https://stackblitz.com/edit/vercel-next-js-x6badq?file=package.json

To Reproduce

• create a new Next 13 app
• add 2 large pages (both need to have a scroll bar)
• add a link at the end of the first page that redirects to the 2nd page
• very important (idk why), create an instance of the font on the second page:

import { Inter } from '@next/font/google';

const inter = Inter({ subsets: ['latin'] });

• run the app
• on the home page, scroll down and click on the link
• notice the scroll position on the 2nd page is not at the top

2nd related issue
Now, remove the font instance (const inter = Inter({ subsets: ['latin'] });) from the second page. Test the app again and notice the scroll bar being at the top but still has a small scroll. It's not top: 0. (Reproduction link)

Temporary workaround

In order to fix this issue, for now, I added this in my main layout.tsx file. I had to convert it to a client component:

const pathname = usePathname()
    useEffect(() => {
        window.scroll(0, 0)
    }, [pathname])

Describe the Bug

Clicking on a link that redirects to a page makes the scroll bar be scrolled instead of having it at the top of the page. Requirements of the bug are described above

Expected Behavior

Expecting the scroll bar to be at the top without removing the font instance from the 2nd page.

To note that, on my real app, I don't have this font instance. Si the bug is probably introduced by some other package.

Which browser are you using? (if relevant)

Chrome 109

How are you deploying your application? (if relevant)

next start

[guitheengineer]

Duplicate of #42492

[bdlowery]

Duplicate of #42492

Not a duplicate. Still not fixed.

[toddalbert]

I'm having the same issue. I really don't want to turn Layout into a client component.

[toddalbert]

Ok, I just did a git bisect to find when this stopped working in my project since it was working originally. It 100% happened after I installed react-icons library. Damn. Is there an icon library compatible with Next that doesn't break the scrolling?

[rimzzlabs]

Ok, I just did a git bisect to find when this stopped working in my project since it was working originally. It 100% happened after I installed react-icons library. Damn. Is there an icon library compatible with Next that doesn't break the scrolling?

I'm having the same issue, are you saying that react-icons can make <Link /> component not scrolling to top? is that the problem? because Im using react-icons too

[hhtoan]

I face the same issue and made a demo here: https://demolink.vercel.app/

Repo: https://github.com/h2toan/next-link-does-not-scroll-to-top

Step to investigate:

Try to scroll down to the bottom, then click in the Link at green box. It only navigates to the gray box, not the top of page (the red and orange box)

My theory is that in /app router, it only scrolls to the top component of the current layout (the top of {children} in layout.js), and if there are some components above {children}, they might not be displayed on the screen (if the total height is greater the height of screen, like 100vh?)

[nhonx]

I encountered this issue but I figured out the cause is I use a custom scroll container instead of window or document.

[bdlowery]

The issue happens when you have a sticky header.

here's a fix:

'use client'
export default function Scroll() {
	// when clicking a link, user will not scroll to the top of the page if the header is sticky.
	// their current scroll position will persist to the next page.
	// this useEffect is a workaround to 'fix' that behavior.

	const pathname = usePathname();
	useEffect(() => {
		window.scroll(0, 0);
	}, [pathname]);
	return <></>;
}

Put the component in your layout.jsx file

export default function RootLayout({ children }: { children: React.ReactNode }) {
	return (
		<html lang="en">
			<Scroll />
			<body>{children}</body>
		</html>
	);
}

problem solved until they fix it.

[Uni2K]

Still not fixed in the current version 13.5.6.

[wscotten]

Still not fixed for me either. Having to use a window.scroll(0, 0); component is silly. Next should fix the bug.

[Andrew9614]

Next 14.0.3 still not fixed

[cong1223]

"14.1.3" still not fixed

[tomferez]

For what it's worth, scrolling works well on the latest versions of Safari and Firefox for iOS (-- and has always worked well on these apps, at least with my project), but is random on Chromium (Chrome version 119.0.6045.169, Edge version 119.0.2151.105) for iOS. Impossible to narrow down the root cause as it seems to be completely random.

Furthermore, I have never had any issues with Chromium for MacOs.

[aleksei-stukalov]

The issue seems to be related to the state of iOS Safari viewport. Since there is two states that the viewport can be at: small and large - the issue only appears when clicking Link at large viewport state. If I scroll down the page and then slightly up to get my viewport back to small state - and click the Link - the next page opens up at the top.

It is visible at the Timelines - on the initial page open - the browser is at small state, and then changes to large state, I am assuming, to get back to the state it had been before the click.

Using normal anchor tag, instead of Link router, works for me, since browser just refreshes the page.

iOS_issue.MP4

[Gr33nLight]

bump - facing same issue with next@13.5.2, using a global style for the body "min-h-screen" and when the viewport shrinks in height and is not 100vh anymore the issue happens. For example I have a page with return <></> until the content is loaded, had to return div with h-screen in loading state as well to "fix" the issue

[JesseKuntz]

I just ran into the same issue. I had some "modal" components placed further down in the DOM than my main content, and it looks like Safari was jumping down to them to focus them instead of staying at the top of the page. Placing them higher in the DOM fixed the issue, so my suggestion is to also check out what elements you're rendering below the rest of your content.

[samcx]

@LouisGS44 Please submit a separate bug report as this example does not involve a sticky header.

In the meantime, since this thread has veered from the original issue, I will be moving this to discussions.

[LouisGS44]

There is a sticky header in my example.
It's the gray area, I applied an opacity of 0.8 in order to see the scroll position behind the header.
I had the scroll issue when migrating my production application from pages to app folder, so I tried to make a simpler example and it's the same.

[guylepage3]

Why was this moved to a discussion from an issue?

[t-aburasoba]

I have same trouble..
But in my env, the specific device has this trouble (Galaxy). iOS, web, pixel is fine.

[samcx]

A separate issue was created for scroll issues when using sticky header → #64441. This is separate issue of the original confusion with regards to scroll behavior, which was in the absence of sticky headers, parallel routes, etc.

[JacobJaffe]

After seeing https://stackoverflow.com/questions/76605889/force-link-component-to-scroll-to-top-of-layout-in-next-js-13,
I found that having a wrapper in my root layout with overflow-x-hidden was causing this behavior

[chriscodingxyz]

This issue is giving me such headaches! I really dont want to update every single page and add some padding/margin ontop. Nextjs plz fix this already!

[chriscodingxyz]

So I fixed my issue by deleting this which wrapped my layout.tsx: <html lang="en"className="!scroll-smooth">

After getting rid of the tailwindcss className of "scroll-smooth", my app functioned as intended. Thank god because last thing I wanted to do was add a bunch of useEffects to my app!!!

[Foued80]

Removing scroll-behavior: smooth!important; from global.css fixed the issue

[poorscousertommy8]

Hi mates!
I had the same problem. One solution was (as already posted) to put an empty div at the beginning, but I didn't really like that.
What ultimately caused my problem was that I retuned a React.Fragment in the first place.
A repo was posted here in a previous post, and you can also see the React fragment there, see:
https://github.com/hhtoan/next-link-does-not-scroll-to-top/blob/master/app/page.tsx

I haven't tried it, but I guess the problem in this repo would be solved if the fragment was deleted.

[totodot]

Next 14.2.0 still having the #issue. I have a sticky header at the top of the layout. When a link is cliqued, if the scroll position is lower than the header height is doesn't scroll. If the scroll position is bigger, it scrolls correctly at the top of the page.

Enregistrement.de.l.ecran.2024-04-12.a.23.31.18.mov

Same problem, when using tabs (nested navigation). Problem exist after place header above tabs. It's not sticky or fixed. After remove header or scroll on previous page more that header height it's works.

[MuhammadMujtabaa]

Removing scroll-behavior: smooth!important; from global.css resolved the issue successfully by eliminating the unintended smooth scrolling effect across the entire site.

[MuhammadMujtabaa]

Removing scroll-behavior: smooth!important; from global.css resolved the issue successfully by eliminating the unintended smooth scrolling effect across the entire site.

[andrewmcoupe]

This also worked for me.

[musjj]

I also started having this problem when I was separating my page into a server-rendered layout.tsx and a client-rendered page.tsx (there was no layout.tsx before). I tried removing my sticky header but the problem still persists.

From what can I see, the {children} is always visible on the first load. But there seems to be a certain threshold with the distance from the top of the page until the bug occurs.

[samcx]

Hi everyone—

I will be closing this discussion as the explanation for this issue has been added to our documentation → https://nextjs.org/docs/app/api-reference/components/link#scroll (additional comment), a separate issue with sticky headers has been filed, and several solutions have been found (e.g., removing scroll-behavior: smooth!important;).

If you find a separate issue that does not follow the current scroll behavior, please feel free to file a new bug report so we can take a look!

[sannajammeh]

I just wonder why.

We use scroll-behaviour: smooth for hash navigation and similar. I don't get why its unable to scroll to the top if that is enabled.
Simply adding onClick={() => window.scrollTo(0,0)} does the exact thing we wish, but adding it to every Link component in the project is redundant.

[resthedev]

Hi @samcx
Has there been additional thought given to this behavior: #64435 (comment)

[samcx]

@resthedev Unfortunately no, not at the moment. Is your Layout always larger than the viewport, to where your Page is not visible in the viewport? A way around this would be to re-organize what is in your Layout versus Page.

[resthedev]

In my real use case, my layout isn't bigger than the page. However part of the page does have some loading to get data before being displayed. Maybe since the content of the page loads in later and Next doesn't detect it in the viewport, it tries to scroll to it later? Would that be the case?

[guylepage3]

I don't think this is solved tbh. If you close this another one will need to be opened. This isn't stale.

[samcx]

@guylepage3 As far as I'm aware, I wasn't able to identify an actual bug (in general) with the scroll behavior in App Router. There was a separate one open with sticky headers I believe. The intention was to move away from a generic "link scroll doesn't work" issue to actionable edge cases with a single :repro:. It becomes unmanageable if people continue to lump a "a scroll issue" into one big thread. It's better left to a discussion for folks to find to find a possible solution or understanding to the behavior (if not a bug).