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.

[maisoncastro]

How did you fix this btw? I'm using Lenis scroll and despite what has been indicated in #64435 (comment), the issue still persists.

[RobinOstner]

@maisoncastro I had also some issues with using Lenis where the scroll position of the old page would just stay for the new page and it didn't scroll to the top at all. This was caused by the smoothing of the scroll still happening when clicking the link. I solved this by creating a wrapper around the link components, which resets lenis before navigating.

export default function CustomLink({
  children,
  className,
  ...linkProps
}: CustomLinkProps) {
  const lenis = useLenis();

  const onClick = (e: React.MouseEvent<HTMLAnchorElement>) => {
    lenis?.stop();
    lenis?.start();

    linkProps.onClick?.(e);
  };

  return (
    <Link {...linkProps} onClick={onClick} className={className}>
      {children}
    </Link>
  );
}

Maybe you are running into the same issue and this helps. Although I do have to say that I don't think this is actually connected to the issue discussed in this thread.

[maisoncastro]

Just tried this, and sadly still not working :(. Thanks again though!

EDIT: It's fixed. You're a lifesaver. I just fucked up in implementation, but now it's starting at the top. Mucha gracias bro!

[csiszar197]

I fine-tuned your suggestion a little bit, and now it works perfectly. Thanks for the help! Here's what I'm using now:

interface CustomLinkProps extends AnchorHTMLAttributes<HTMLAnchorElement> {
  children: ReactNode;
  className?: string;
  href: string;
}

export default function CustomLink({
  children,
  className,
  href,
  ...linkProps
}: CustomLinkProps) {
  const lenis = useLenis();

  const onClick = (e: MouseEvent<HTMLAnchorElement>) => {
    lenis?.stop();
    lenis?.start();

    linkProps.onClick?.(e);
  };

  return (
    <Link {...linkProps} href={href} onClick={onClick} className={className}>
      {children}
    </Link>
  );
}

[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.

[carlos-dubon]

this breaks back/forward navigation scroll position

[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 [email protected], 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.

[ghost]

I have the same exact problem, the workaround as mentioned above is to use a hidden client component with a useEffect and scrollTo but I'm tired of fixing Nextjs's unwanted bugs in this fashion.

[daveycodez]

Zzzzzzzz

[daveycodez]

How am I supposed to maintain confidence in Vercel hosting if you guys won’t even talk about fixing something as basic as this

[FKuna]

So I tried this workaround:

const LenisScrollEffect = () => {
  const pathname = usePathname();
  const searchParameters = useSearchParams();
  const lenis = useLenis();

  useEffect(() => {
    lenis?.scrollTo(0, { immediate: true });
  }, [pathname, searchParameters, lenis]);

  return null;
};

It works great for scrolling, but after adding this, I started getting the "Rendered more hooks than during the previous render" error, but only on my not-found.tsx page. The issue occurs only on Safari and on mobile devices in any browser, but it's intermittent — sometimes the page loads fine, and other times it throws the error.

Does anyone have an idea why this might be happening or how to fix it?

[daveycodez]

Why are you hosting a hackathon instead of fixing this? @leerob

[agurtovoy]

I narrowed this down to a known rendering/findDOMNode bug in client/components/layout-router.js. Essentially what happens here is that the findDOMNode call on the InnerScrollAndFocusHandler instance after a client-side page navigation returns a more or less random node inside the document's <head>, and the code that is supposed to handle scroll to the top subsequently bails out because it cannot find a visible DOM sibling (since it's searching within <head>).

A simple workaround is to comment out the process.env.NODE_ENV !== 'production' check that is currently guarding the detection of this issue, and to point the DOM node to <head /> itself; the existing logic in the while loop will then reset it to <body>, which is what we want:

       // Verify if the element is a HTMLElement and if we want to consider it for scroll behavior.
       // If the element is skipped, try to select the next sibling and try again.
       while (!(domNode instanceof HTMLElement) || shouldSkipElement(domNode)) {
-        if (process.env.NODE_ENV !== 'production') {
+        // if (process.env.NODE_ENV !== 'production') {
           if (domNode.parentElement?.localName === 'head') {
             // TODO: We enter this state when metadata was rendered as part of the page or via Next.js.
             // This is always a bug in Next.js and caused by React hoisting metadata.
             // We need to replace `findDOMNode` in favor of Fragment Refs (when available) so that we can skip over metadata.
+            domNode = domNode.parentElement
           }
-        }
+        // }

         // No siblings found that match the criteria are found, so handle scroll higher up in the tree instead.
         if (domNode.nextElementSibling === null) {

You can apply this patch locally using pnpm patch/bun patch/patch-package.

[shehi]

I hope Vercel is reading this...

[samcx]

@agurtovoy @shehi We have taken a look at this!

Unfortunately, this will likely fix some cases but break others.

React is working on first-class support for this! → facebook/react#32814.

[agurtovoy]

@samcx Can you elaborate on what cases it's likely to break?

[joshAntoniuk]

It might be worth mentioning - my issue was related to either Framer Motion, or a Carousel component. Regularly, the Link has expected behaviour, however, putting the Link inside a carousel would give the unintended scroll behaviour. A regular anchor tag worked. What I believe to be the issue was something that the Carousel had, which made the intended scroll behaviour of Link affect the Link's parent, rather than the whole page. While not ideal, I just used router.push(link) on that button. I am sure there could be a less band-aid-y solution, but I suspect checking for parent scroll behaviour or overflow or something along those lines might help.

[joshAntoniuk]

Update/Fixed: The problem for me ended up being middleware regarding the routing of the app. My team had language functionality built into the app, and the middleware for the locale seems to interrupt the router logic. My guess is that the navigation is client side, and middleware is server side. Adding the correct locale fixed the issue for us.

For others, if you are using middleware, I would suggest making sure the middleware is working as expected - although I understand this might not be the issue for a lot of people.

[bendesilva]

FWIW I was experiencing the same issue as #64435 (comment) on Chrome on iOS only when clicking a link from the bottom of the page, which led me to this discussion. It was dependent on whether Chrome's browser UI chrome was either collapsed or expanded, but clicking a link at the bottom of the page would either be at the top or ~100px from the top.

It turned out the cause was the min-h-screen Tailwind class name on a top level wrapper element providing the property min-height: 100vh, which as we know represents the largest viewport value irrespective of the visible viewport at the time. When I changed this to min-h-svh which provides a property of min-height: 100svh – which is the smallest viewport height – the links worked as expected both in the expanded and collapsed browser chrome states, and the new page always loaded at the very top.

I'd hazard a guess that there's a moment in between navigation when the DOM is replaced on the page where the height changes, and the browser's scroll position ends up as the difference between 100vh and the visible viewport upon navigation (100svh) when setting a min-height of 100vh.

Putting this out there for anyone experiencing this issue specifically, as it seems like there are a few different loosely related issues in this discussion.

[astronaute77]

15.3.5 bug still present.

Is there a ticket for this?

[MHBahrampour]

they say this is the normal behavior, so not a bug.
#69752

[grazianodev]

Came across this bug when using the below component in a loading.tsx file:

export const TextSkeleton = ({overrideStyles, rowCount = 1, rowSize = 'md', ...props}: TextSkeletonProps) => (
  <Box overrideStyles={styles.textSkeleton}>
    {Array.from({length: rowCount}, (_, i) => <Skeleton key={i} overrideStyles={cn(styles[rowSize], overrideStyles)} {...props} />)}
  </Box>
)

The bug is gone if I don't dynamically generate multiple items, so I guess the problem is with the app not knowing in advance the array length or something?

Fixed by dropping loading.tsx and using Suspense in page.tsx instead.

[agurtovoy]

#64435 (comment)

[um1chc5]

I end up using <a><a/> or this

<button
  key={key}
  onClick={() => {
    window.location.assign(`/services/${service.slug}`)
  }}
>
  ///...
</button>

[Schubzz]

If you manage to build a glowing hammer (keeping scroll position on navigating back), but the hammer can’t actually drive a nail into the wall (doing normal <a> tag things), then it’s unfortunately just glowing junk
(or maybe I’m using it wrong — but this issue strongly suggests otherwise).

So for now, I have to fall back to simple <a> tags.

[carlos-dubon]

This is still present in 15.5.3

[Rathalin]

Unfortunately, I think it works as intended.

[...] When you navigate to a new Page, scroll position will stay the same as long as the Page is visible in the viewport. [...]
https://nextjs.org/docs/app/api-reference/components/link#scroll

[boicetomlin]

I was experiencing this same issue verbatim. I discovered it was the styling in my loading.js template. the height of the loading template appears to be added to the overall height of the page or it is altering the scroll top position. I noticed in the code that @IonelLupu posted about this issue there was not a loading template so I added one with no height and reloaded and the issue was resolved. so maybe this has something to do with the default nextjs loading state.

added loading template:

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

[startydev]

❌ This is still present in 15.5.4 ⚠️
Any updates on this? I've noticed this happens when I create a loading.tsx component instead of using for a page.tsx. Interestingly, if I create a loading.js, it works, but when I import my skeleton using tsx, it fails again.