[NEXT-378] Next 13: Navigation with Link does not scroll up the page

[alexvcasillas]

Verify canary release

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

Provide environment information

Operating System:
Platform: linux
Arch: x64
Version: #1 SMP Mon Sep 19 19:14:52 UTC 2022
Binaries:
Node: 16.15.0
npm: 8.5.5
Yarn: 3.2.4
pnpm: N/A
Relevant packages:
next: 13.0.2
eslint-config-next: 13.0.0
react: 18.2.0
react-dom: 18.2.0

What browser are you using? (if relevant)

Chrome 107.0.5304.87

How are you deploying your application? (if relevant)

Vercel

Describe the Bug

When navigating between pages using Link, the page does not scroll up by default wich is supposed to be the default behaviour of next/link

Expected Behavior

The page scrolls up when switching pages unless I manually disable this feature of next/link

Link to reproduction

https://beta.otpfy.com/

To Reproduce

• Access https://beta.otpfy.com/
• Scroll down until you see the "Get started for free" button
• Click the given button
• Check that when navigating to the auth page the scroll is preserved and not scrolled to the top

:

_{From SyncLinear.com | NEXT-378}

[semy]

Same for me... How to fix that?

[Fredkiss3]

I think it scrolls up to the nearest <div data-nextjs-scroll-focus-boundary />, this div is automatically created when you wrap your page in a layout. It is supposed to assure scroll restoration within layouts.

you can see in the video below :

Enregistrement.de.l.ecran.2022-11-20.a.00.37.07.mov

[semy]

@ Fredkiss3 Thanks for your answer :) Yes you are right, but what if I don't want to? Normally I want it to just scroll all the way to the top when clicking on another page. That should be clarified.

[Fredkiss3]

I don't know, they added this feature because it seemed really nice (that's what I know, but maybe I'm wrong), but it seems like it requires the creation of a new react API to do so.
What I would have liked from them is that they don't include the scroll restore functionality before it is implemented by react.

(sorry for my broken english)

[rshaul]

I thought this scrolling behavior was a bug at first and rolled back to the pages directory because of it.

Scrolling to top after clicking a link seems like it should be the default behavior to match "web" expectations and maybe you should have to opt into this scroll to nearest layout container div behavior if that's what you want?

Or maybe rather than scrolling to the top of layouts inner content, it should scroll to the top of the layout itself to give context to the page navigation? So ie if you are just using a root layout it would always just scroll to the top of the entire pag. If your nested layout includes tabs it would scroll to show the tabs also.

[rijk]

For now can be fixed by adding a <ScrollUp /> component to your page:

'use client'

import { useEffect } from 'react'

export default function ScrollUp() {
  useEffect(() => window.document.scrollingElement?.scrollTo(0, 0), [])

  return null
}

[trevorpfiz]

I have some routes using the Tailwind UI Sidebar Layout where html and body need h-full. So this wasn't working. more details

So I had to use this on those routes:

'use client';

import { useEffect } from 'react';

export default function ScrollUpBody() {
  useEffect(() => document.body?.scrollTo(0, 0), []);

  return null;
}

Not fun.

[Fredkiss3]

Hey, are you still having the same problem after the latest canary release ? You can install it with next@canary.

I've seen that they removed the unnecessary divs appearing inside children of layouts in this PR : #43717

[trevorpfiz]

I have been curious as well. There is a bug on canary that breaks my app, and maybe all Windows users. issue

[rosszurowski]

For others who come across this issue, I ran into the same thing, but was able to fix it by removing an unnecessary layout. My directory structure looked like:

app/layout.tsx
app/page.tsx
app/blog/[...slug]/layout.tsx
app/blog/[...slug]/page.tsx

In my case, navigating to one of the blog/2020/post-name pages had the page start half-way down, without scrolling back up to the top. Looking at the DOM structure, there were two layers of <div data-nextjs-scroll-focus-boundary /> elements.

I found that removing my app/blog/[...slug]/layout.tsx and wrapping my one-off layout into app/blog/[...slug]/page.tsx instead fixed the issue, since now there was only one layer of layouts rather than two. I moved common layout code into a separate component to share between the two pages where it's needed:

app/layout.tsx
app/page.tsx
app/blog/[...slug]/page.tsx
components/layout.tsx

For a content-based website like the one I was working on, it was a good reminder that nested layouts are probably more meant for apps with truly nested frames rather than a single view. I guess hearing the word "layout" made me think it'd replace my Layout components 1:1.

[valse]

Hey, are you still having the same problem after the latest canary release ? You can install it with next@canary.

I've seen that they removed the unnecessary divs appearing inside children of layouts in this PR : #43717

Hi, I'm using the latest 13.0.7-canary.6 version but I have the same issue

[trevorpfiz]

I'm using 13.0.7 and the issue is better, but it still does not scroll all the way up if I want it to. It will scroll right below the header.

[davidcm62]

Same here. We're trying to add a simple layout with a shared header and the main content. On navigation, the page doesn't scroll to the top and the header is always hidden. We're using 13.0.7

[AndrewIngram]

For now can be fixed by adding a <ScrollUp /> component to your page:

'use client'

import { useEffect } from 'react'

export default function ScrollUp() {
  useEffect(() => window.document.scrollingElement?.scrollTo(0, 0), [])

  return null
}

Won't this also be triggered when using the back button though?