Scroll Position Issue When Changing Pages

[MHBahrampour]

Link to the code that reproduces this issue

https://github.com/MHBahrampour/page-scroll-issue

To Reproduce

1. Start the app in any mode
2. Adjust the window height and zoom until you can observe both scenarios (see the videos):

• Pages with enough height to display page component
• Pages without enough height to display page component

Current vs. Expected behavior

Current Behavior

There are two problems with the scroll behavior when navigating between pages:

1. Inconsistent scroll behavior
2. Unwanted scroll to the top of the page

Note: Layout sections are shown in blue, and Page sections in red.

1. Inconsistent scroll behavior (page has enough height):

inconsistent-scroll.mp4

As shown in the video, when clicking on a group card, sometimes the page scrolls to the top of the group layout, while other times it scrolls to the middle of the new page, cutting off a portion of the layout.
This happens even when the new page (e.g., /groups/rent/expenses) has enough height to display the entire layout and some portion of the page itself. According to Next.js docs for Link component, this is the expected behavior which I think makes it a bug and the new page shouldn't scroll at all in this case.

2. Unwanted scroll to top (page doesn’t have enough height):

scroll-to-top-of-page-issue.mp4

As seen in the video, there are two issues in this scenario:

• When clicking a group link (e.g., /groups/rent/expenses), the layout section isn’t visible, which creates a poor user experience.

• When clicking on tabs inside the group layout, the tab list itself isn't visible, making it unclear which tab is currently active. If the wrong tab is selected, the user must scroll up to correct it.
  Although this issue can be addressed using scroll={false}, I wanted to highlight it, as there may be other situations where scroll={false} isn't a complete fix. BTW for this one Firefox behaves like scroll={false} is set.

Expected Behavior

Here is what I think is the expected behavior for both problems:

1. Inconsistent scroll behavior:

The scroll behavior should be consistent. The scroll position of the next page should not be influenced by the scroll position of the current page (this is different from preserving the scroll position using scroll={false}.

2. Unwanted scroll to the top of the page:

While having the option to scroll to the top of the page could be useful in certain cases, it doesn't apply universally. It would be beneficial to have an option to opt-out of this behavior or make it opt-in where necessary.

I've noticed similar open and closed issues on this topic and have tried to be as detailed as possible, so please take this into consideration.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Fri Mar 29 23:14:13 UTC 2024
  Available memory (MB): 7757
  Available CPU cores: 16
Binaries:
  Node: 20.12.2
  npm: 10.7.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.8 // Latest available version is detected (14.2.8).
  eslint-config-next: 14.2.8
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Navigation

Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Other (Deployed)

Additional context

Project is created using:

• npx create-next-app@latest --typescript --tailwind --eslint

Browsers that I tested:

• Chrome 128.0.6613.120 (Official Build) (64-bit)
• Firefox 130.0 (64-bit)

[samcx]

@MHBahrampour Thank you for submitting this! This made me realize our documentation needs to be updated.

• docs(link): update scroll docs #69894, docs(link): additional updates with regards to scrolling behavior in App Router #69896
• https://nextjs.org/docs/app/api-reference/components/link#scroll

when clicking on a group card, sometimes the page scrolls to the top of the group layout, while other times it scrolls to the middle of the new page

This is actually expected, and I updated the documentation to reflect it correctly (thank you for flagging this!). We're maintaining scroll position when using <Link>—similar to how browsers maintain scroll position when using back and forwards navigation.

When clicking on tabs inside the group layout, the tab list itself isn't visible, making it unclear which tab is currently active.

I would argue your tab list should be set to position sticky instead of changing this behavior on Next.js's side. Our code actually bails out correctly when it notices a position sticky.

• x-ref: Fix scroll bailout logic when targeting fixed/sticky elements #53873

I wanted to highlight it, as there may be other situations where scroll={false} isn't a complete fix. BTW for this one Firefox behaves like scroll={false} is set.

Can you highlight where this wouldn't be a complete fix? I'm also not seeing this issue on Firefox.

[MHBahrampour]

This made me realize our documentation needs to be updated.

Thanks for the update! The description now more accurately reflects the behavior.

However, what if this isn't the behavior I want? I believe that, regardless of the situation, users should see the entire page (Layout + Page) when visiting a completely new page. Currently, there isn't a proper way to achieve this aside from using hacks or the default HTML tag, which doesn't need much explanation as to why it's not an ideal solution.

I'm not an expert, but I honestly don't understand why Link behaves this way. The browser's back and forward buttons are meant for navigating already visited pages, so it's fine to land in the middle of a page. But in Next.js, we usually use Link to navigate to new pages that users are visiting for the first time, so they may miss some content.

If it were just me, I wouldn’t question this behavior, but I’ve seen other developers facing the same issue, so it’s safe to say the current behavior isn't sufficient for all situations. That’s why I’m still kindly (and a bit desperately) asking for an option to opt out of this behavior.

I would argue your tab list should be set to position sticky instead of changing this behavior on Next.js's side.

Making the tabs sticky isn’t what I want because they would always remain at the top of the page, and I already have a sticky header. Additionally, as shown in the video, when I make the tabs sticky and the window height isn’t enough to fit the entire page, Link scrolls to the top of the page, causing the sticky tabs to overlap part of the page content.

making-tabs-sticky.mp4

Can you highlight where this wouldn't be a complete fix?

Not really, let's forget that.

[samcx]

I believe that, regardless of the situation, users should see the entire page (Layout + Page) when visiting a completely new page.

I disagree with this.

The Layout was designed to render only once. Which means, it's really only viable for anything that's truly static (only needs to render once). It's fine if that only your root Metadata, a sticky header, wrapping your Pages with <Provider>s, etc. This is a good thing—you'd only want to render things that are truly static only once. No dynamic "content" really should be in your Layout. If you're arguing the Rent title needs to always be visible, then I would argue that needs to go to your Page.

You could probably instead add another dynamic Page ([groupId]/[group]) and get rid of your inner Layout. This would also reduce the number of files you have.

but I’ve seen other developers facing the same issue, so it’s safe to say the current behavior isn't sufficient for all situations.

We have seen this as well. As far as I can see so far, folks have been confused with the scrolling behavior, hence there has been updates to our documentation. I also think there is some confusion around how to properly organize Layouts and Pages.

Link scrolls to the top of the page, causing the sticky tabs to overlap part of the page content.

You can give your Page empty height so it does not overlap.

In the meantime, since this is more of a discussion/feature request, I'll be converting this to a discussion.

[MHBahrampour]

the Rent title needs to always be visible

It's about the Layout part (Title, Subtitle, Tabs) and yes I want it to always be visible when the user navigates from a different route, but just because this content is dynamic doesn't necessarily means the behavior is right. Let's say it were completely static, with no fetching of group names or rendering tabs (which is static and only highlights the current route), sometimes the user still couldn't see it, even on their first visit.

If you're arguing the Rent title needs to always be visible, then I would argue that needs to go to your Page.

Consider the Layout part like a Sidenav, which serves the purpose of navigation. Wouldn't you then place it in the Layout? The Next.js tutorial does it. In my case, instead of having this navigation part on one of the sides, it's at the top, and this behavior is causing issues with it.

If it were just for one page, I would move it there, but it’s content that I want to share between several pages.

Here is my route structure—does it seem wrong? I don't think I can create another dynamic route or move the tabs and group name inside each page (expenses, balances, stats), as that doesn't make sense to me. And it's not just my implementation—I’ve seen similar setups in other places too.

As far as I can see so far, folks have been confused with the scrolling behavior

Even though the documentation helps in figuring out what's going on, I think the confusion stems from unexpected behavior, not the docs itself. Either way, let's see if this keeps happening or not.

[samcx]

Consider the Layout part like a Sidenav, which serves the purpose of navigation. Wouldn't you then place it in the Layout?

The Sidenav from the Next.js Learn tutorial I would consider a "sticky" nav.

Many navigation bars on the web (vercel.com, airbnb.com, etc.) are sticky. UX-wise, I don't think it makes sense to have them disappear as you read down. I would then have to scroll all the way back up to navigate somewhere else.

The content in your Inner Layout and your expenses, balances, stats Pages are all the same structurally, so you could combine all of them into a dynamic page.

---

  const basePath = `/groups/${groupId}`;
  const groupName = groupNames.find((group) => group === groupId);

  if (!groupName) return <p>Group not found!</p>;

This can also just be in a not-found.js page → https://nextjs.org/docs/app/api-reference/file-conventions/not-found

[daveycodez]

Bro why do I have to research for 6 hours to figure out why scroll to top isn't working, and I still have no idea how to get it to work. I ripped out my navbar and everything just got a barebones <html><body> layout and only scroll down slightly then navigate to a page and it doesn't scroll to top. Some kind of minimum threshold or something. HUGE BUG. Why is this a discussion?

[daveycodez]

Oh okay so if you use layouts whatsoever it breaks scroll to top. So either don't use sub-layouts or just use a hack to fix scroll to top. Why do we have to use so many hacks...

[t6tv8e]

I'm also relying on a "hack".

I use this client component on my layout:

"use client";

import { useEffect } from "react";

const TopScroller = () => {
  useEffect(() => {
    window.scrollTo({
      top: 0,
      behavior: "smooth",
    });
  }, []);

  return <div></div>;
};

export default TopScroller;

wrapped in:

import dynamic from "next/dynamic";

const DynamicTopScroller = dynamic(() => import("./index"), {
  ssr: false,
});

export default DynamicTopScroller;

Yeah it works, but this is far from a clean fix but it's the only way atm afaik.

[Necmttn]

https://stackoverflow.com/a/76449161/6942552
this was the issue for me, do not add overflow-hidden to html/body

[t6tv8e]

Well I don't have overflow-hidden anywhere on html/body tag and issue still occuring

[hieulvt-2714]

i tried use scroll={false} but it still not working

[adnan-smlatic]

@samcx Your response is dismissively arrogant and misses the core issue.

For 3 decades the standard behaviour on the web has been, you click on a link, you start at the top of the page.

Next.js's current behaviour breaks this fundamental UX pattern. There are hundreds of discussions on this topic and developers implementing workarounds and hacks such as manually scrolling the page to the top, which's a clear signal this isn't working as intended.

Your suggestions to restructure entire applications around this scroll behaviour are diabolical. You're making blind assumptions about the design of the entire layout structure in the app, and even worse the wants and needs of the users.

Converting this bug report to a discussion doesn't address the underlying problem: Next.js makes it difficult to achieve basic navigation UX that users expect. Attitudes such as yours hurt the entire community.

This needs a proper solution, not workarounds or app restructuring.

[cdorfer]

I could not agree more. Despite being a great tool, being that opinionated about things like this (and auth) makes Next.js hard to like.

[banderberg]

It's incredible to me that this has been an issue for multiple years and Vercel shut down the issues page that had been opened on this and kicked it to the discussion forum.

[cdorfer]

Next 14: Same issue here.

We have have an app that uses (different-length) questionnaire structured into 4 pages with redirects in between. The described behavior above that is also inherit to the redirect makes it a terrible user experience.

What makes it even less bearable in my eyes is that anchor points - which given our situation would be the ideal fix - get stripped from the redirect url for some reason.