Gatsby: [v2] Navigating to previously visited pages with <Link> retains scroll position

[robinpyon]

Description

Clicking on a <Link> in v2 (111) appears to scroll you to a previous scroll position (if it exists) rather than scroll you to the top.

Steps to reproduce

I've been able to recreate this in gatsby-starter-default:
https://gatsby-v2-beta-111-scroll.netlify.com/

(The only change is artificial padding added to the first page above the /page-2 <Link>)

• Visit https://gatsby-v2-beta-111-scroll.netlify.com/
• On the home page, scroll down to the page-2 link and click it
• On page-2, now click 'Go back to the homepage'

Expected result

You are taken back to the top of the home page

Actual result

You are taken back to the home page but scrolled down the page (at the exact same position you were when you linked the page-2 link)

Environment

System:
    OS: macOS High Sierra 10.13.6
    CPU: x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 8.11.1 - ~/.nvm/versions/node/v8.11.1/bin/node
    Yarn: 1.9.4 - ~/.nvm/versions/node/v8.11.1/bin/yarn
    npm: 5.6.0 - ~/.nvm/versions/node/v8.11.1/bin/npm
  Browsers:
    Chrome: 68.0.3440.106
    Firefox: 61.0.1
    Safari: 11.1.2
  npmPackages:
    gatsby: next => 2.0.0-beta.111
    gatsby-plugin-manifest: next => 2.0.2-beta.6
    gatsby-plugin-offline: next => 2.0.0-beta.9
    gatsby-plugin-react-helmet: next => 3.0.0-beta.4
  npmGlobalPackages:
    gatsby-cli: 1.1.58

Other notes

• This behaviour doesn't occur on the v1 starter.
• I understand that there was a switch to reach-router, could this be linked?
• Manually adding window.scrollTo(0, 0) / window.scroll({top: 0}) in page componentDidMount had no effect, though it would work after wrapping it in an arbitrary setTimeout - though this yields an initial flash of content in the wrong scroll position.

By default, I imagine the desired behaviour would be for all clicked <Link> elements to scroll you to the top of that target page and that only using the browser back / forward buttons would retain scroll position state in this manner.

[stoutlabs]

I can confirm this same behavior is happening on a couple sites I'm working on. I just noticed it today, but have no idea how long it has been happening. (I came here to search for the same issue or create a new one.)

[Manoz]

Could be related to #7450 ?
I noticed the same behavior. I though it was a feature since it’s not totally stupid.
If I read a very long blog post and click on a link it’s nice to go back where I was without scrolling the whole page, even if it’s a weird behavior.

[colbyhub]

I'd rather it default to the top of the page rather than the previous scroll position, it would create a more predictable experience.
Could the <Link> component default to not scrolling to the previous scroll position, but still have it as an option via a prop?

[DylanVann]

Could be related: https://github.com/gatsbyjs/gatsby/issues/5656

The logic discussed for determining if something is a pop could be the issue. We want to restore scroll on pop (back button pushed), not if you're just going to a link you've been to before.

There is no action on Reach Router so this probably doesn't work anymore: https://github.com/gatsbyjs/gatsby/pull/3775/files

[Chuloo]

Verified, Here's a simple repro using the Blog-Starter .
Clone repo and run npm install followed by gatsby develop.

[thebigredgeek]

So it seems like this might be blocked by a necessary API change to reach-router? Otherwise it sounds like we have to keep a hash of seen routing keys in order to determine push vs pop

[humphreybc]

FYI I'm seeing this not just with previously visited links, but with all links. Unless “previously visited” includes visiting the URL in a previous browser session.

[monsieurnebo]

Same behavior over here.

[ryanwiemer]

I too can confirm this behavior when using gatsbyv2. It is a particularly bad user experience when you have next/previous links at the bottom of the page as it keeps the user at the bottom.

[jkimbo]

We came across this issue on https://www.zego.com and developed a work around by using our own custom Link component that sets a flag on the window:

// components/Link.js
import { Link as BaseLink } from 'gatsby';

if (typeof window !== 'undefined') {
  window.__navigatingToLink = false;
}

const Link = ({ children, ...props }) => (
    <BaseLink onClick={() => { window.__navigatingToLink = true; }} {...props}>
        {children}
    </BaseLink>
);

Then in gatsby-browser.js:

// gatsby-browser.js
exports.shouldUpdateScroll = () => {
  if (window.__navigatingToLink === true) {
    return [0, 0];
  }
  return true;
};

exports.onRouteUpdate = () => {
  window.__navigatingToLink = false;
};

It's pretty hacky but it works. All our page links scroll to the top of the page like expected and the back button still maintains the scroll position on the previous page.

[CanRau]

great thanks for the tip @jkimbo that works 👍

[KyleAMathews]

@jkimbo great solution! I'll add that to core while we're awaiting a fix upstream in @reach/router.

[KyleAMathews]

Here's the link to the @reach/router issue https://github.com/reach/router/issues/119

[steverandy]

I'm using v2.0.0-rc.24 and it seems to be having similar issue again.

[ryanwiemer]

@KyleAMathews,

Did your temporary fix get reverted or canceled out somehow? I am seeing the undesirable scrolling behavior again using v2.0.0-rc.25.

[davidbailey00]

Some navigation code was rewritten recently which caused this behaviour to appear again - I think this is on @pieh's todo list

edit: see https://github.com/gatsbyjs/gatsby/pull/7812#issuecomment-419941216

[ryanwiemer]

@davidbailey00 and @pieh,

Thanks for the update and background info! Hopefully this gets resolved in the near future as v2 has been officially released.

Let me know if you need help with anything.

[pieh]

Yeah, I probably broke it and will take a look on this

[ghost]

I saw this behavior on gatsbyjs.com (Gatsby 2.0.5; gatsby.org with 2.0.9 doesn't have this) today and found it quite nice. Could this be recreated for a case (and others) @Manoz mentioned? Or do you think it is totally user unfriendly?

[pieh]

@cardiv can you try adding this to your gatsby-browser.js:

exports.shouldUpdateScroll = ({
  routerProps: { location },
  getSavedScrollPosition
}) => {
  return getSavedScrollPosition(location)
}

[ghost]

Thanks, @pieh! I will try that on occasion. 👍

[macguirerintoul]

Hi there, I believe I'm still having this issue in Gatsby 2.4.5. I've tried @jkimbo's solution but I'm still getting the same result. It can be seen on this page of my site, at the bottom of the page when clicking to ROAR. When clicking back to The Switch, the scroll position is retained.

Edit: For anyone looking for a workaround, this worked for me.

[CanRau]

I'm on Gatsby 2.0.62 now and my custom scroll behavior stopped working

Here it's still working, especially when navigating within the page it's scrolling to the main-nav to skip the header https://5c02ee4941174f0c53519200--gaiama.netlify.com/en it seems the upgrade from 2.0.31 to 2.0.60/62 broke it

Trying to figure out what changed, any hints?

[pieh]

@CanRau Do you use gatsby-remark-autolink-headers - if so this is very likely https://github.com/gatsbyjs/gatsby/pull/9657

--edit:
possible solution to this would be for gatsby to prefer results of last shouldUpdateScroll and not the first one, so it prioritize user code and not plugin code and add warning if multiple things implement this API to let user know

[CanRau]

Yes, that sounds very likely, maybe it could be interesting for the plugin to offer an option to disable shouldUpdateScroll, and maybe even an importable function one can use in it's own shouldUpdateScroll implementation so you can decide for yourself how to prioritize?!
And besides this complexity I like your proposal 👍

What would be the best hook/way to autolink all headers no matter if the page originates from markdown or not? Not sure which ssr-api to use

I disabled gatsby-remark-autolink-headers for now as it's not super important I think, I enjoy the auto skipping of the header more 😁 and now it works again (gaiama.org), so thanks for the quickfix @pieh 🥇

[vinayan3]

Any updates on this? I've tried the hacks and it isn' working for me on the "gatsby": "^2.0.75",

[alanonthegit]

Same here. On the latest version

[vinayan3]

@ar-stackrox I am digging through this again because the scrolling thing has been pretty irritating. I found out that window.scrollTo doesn't work when you have these following CSS statements

html, body { height: 100%; overflow:auto; }

My code base had that and I've changed it to

html {
  width: 100%;
  height: 100%;
  overflow: auto;
}
body {}

I found this solution on . https://stackoverflow.com/questions/1174863/javascript-scrollto-method-does-nothing

For now this seems to be a workaround where new pages now scrolled to the top.

[brookslyrette]

Seeing this as well on: 2.4.7

[davidbailey00]

Hi everyone, I've just tested this out locally and can't see any problems with the current scroll behaviour. I can see the issue in the site @mrintoul, linked but this isn't occurring for me, so I'm suspecting it was fixed with a recent update.

From what I can tell there are some websites linked which highlight the problem, but reproduction repos linked in the comments - please could someone create a reproduction for us to investigate? I'd love to get this fixed if it's still an issue, so that using the scrollTo hack is unnecessary :)

[AllanPooley]

Hi guys, debugging this for a few hours last night, to no avail.

However, this morning I was blessed with an epiphany sent by the software engineering gods! 🕊️

I had some pretty funky styles to make a togglable navigation drawer / menu appear and disappear by pushing away the app's main containing element.

To make this work, I had added:

html {
  overflow: hidden;
}

In my case, removing this style fixed the behaviour!!

Hope this helps someone else.

[thundernixon]

@davidbailey00 I'm currently having this issue.

Here's a repo that reproduces this issue on gatsby v2.0.118 (currently the latest version):

https://github.com/thundernixon/gatsby-link-scroll-test

Not only is it linking to previously-scrolled-to spots in pages (bad), but it’s also linking to the current location on unvisited pages (worse). That is, the pagination at the bottom of a “blog post” type of page will link to the bottom of the next page. I also have a header drop-down menu with links to different pages, and these also don't link to the tops of these pages.

---

UPDATE: Nevermind; it was an issue with how I was using Gatsby Transition Link. It was resolved at https://github.com/TylerBarnes/gatsby-plugin-transition-link/issues/21.

[davidbailey00]

@thundernixon Thanks for your update! I'll presume there's no further issue

@AllanPooley Please could you share your repo, or a reproduction? It sounds like this could still be an issue, even if it only happens with the body styled as overflow: hidden, so ideally we'd like to get this fixed for all cases :)

[ergunpp]

Hi,
I have tried as @jkimbo with my project but I'm still having the same problem. I have added a Link.js under components, which I import to pages linking to other pages. I also added the code to my gatsby-browser.js. Same problem

[davidbailey00]

@ergunpp Please could you share your repo, or a minified reproduction, so we can investigate this?

[ergunpp]

@davidbailey00 repo name: ergunpp/chefschoice

[t2ca]

The same issue currently exists when using semantic-ui-react and it's because of the following css code:

body {
  height: 100%;
}

So i fixed it with the following:

html {
  height: initial;
}

[ergunpp]

Hi, my repo is ergunpp/chefschoice

On 9 Mar 2019 Sat at 18:05 David Bailey [e-mail] wrote:

@ergunpp https://github.com/ergunpp Please could you share your repo,
or a minified reproduction, so we can investigate this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gatsbyjs/gatsby/issues/7454#issuecomment-471187307,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AXv1VxuNMbJQ0E4PjF64PAMM8g5OKYxKks5vU82qgaJpZM4WDB7b
.

[eagleeyejack]

Had this problem all day today digging through various threads looking for the answer, figured out a workaround even though it's not ideal.

I converted my index.js file into a class-based component and then on componentDidUpdate I added

componentDidUpdate() { window.scrollTo(0,0); }

The site I'm building is a one pager with a '/privacy-policy' for context.

It's not pretty but now behaves the expected way. I have a feeling it's something to with my styles (overflow, height:100%, are some suggestions I've had from forums).

I could replicate the issue when I started adding my styles back in.

Will post an update if I figure out the culprit.

[davidbailey00]

@ergunpp I just had a look at your site - it seems the problem is caused by your overflow-x: hidden and styling with the body tag. If you remove this property, as well as the overflow-y property, and then fix the page overflowing by changing various instances of 100vw to 100%, the problem is fixed :)

[davidbailey00]

I think after @pieh's fixes, any problems occurring are due to the scroll-behavior package, which is outside of our control, since the scroll update events seem to be firing correctly.

[KyleAMathews]

If scroll-behavior has problems, we can PR fixes there. We've done that several times.

[davidbailey00]

@KyleAMathews I think it's not even a problem with scroll-behavior - even calling window.scrollTo(0, 0) in the console doesn't work with some of those styles applied, so I think this isn't something we can fix, apart from telling people not to set overflow: hidden. Should we close?

[ergunpp]

@ergunpp I just had a look at your site - it seems the problem is caused by your overflow-x: hidden and styling with the body tag. If you remove this property, as well as the overflow-y property, and then fix the page overflowing by changing various instances of 100vw to 100%, the problem is fixed :)

Hi @davidbailey00, Your suggestions worked like a charm. Thanks for the great help!

[gatsbot[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.

If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

Thanks for being a part of the Gatsby community! 💪💜

[davidbailey00]

Closing, since this has been fixed (or else caused by dodgy plugins / CSS). Please open a new issue if any further problems occur :)

[nandorojo]

This worked for me.

To scroll to the top, make sure your path starts with /. Example:

// this works
<Link to="/some-path" />

I realized it wasn't scrolling to the top when I didn't have a / at the start like this:

// this doesn't work
<Link to="some-path" />

Not sure if that works for every case, but it worked for me. Hope it helps.

[mavam]

@t2ca your html CSS tweak fixed it for me after trying pretty much everything else here. 💯

I'm also using Semantic UI React and have added the following to site.overrides:

html {
  height: initial;
}

[rishichawda]

After wasting a whole hour going through all the issues and references, nothing worked except manually setting the scrollTop on document.body to 0 like so:

export const shouldUpdateScroll = () => {
    document.body.scrollTop = 0
}

Works for both refresh and page visits.

[Uhiyamind]

This worked for me.

gatsby-browser.js

exports.onInitialClientRender = () => {
  window.scrollTo(0, 0)
}

I found this solution on
https://github.com/gatsbyjs/gatsby/issues/19488#issuecomment-554007194

[lvtz]

This worked for me.

gatsby-browser.js

exports.onInitialClientRender = () => {
  window.scrollTo(0, 0)
}

It does not work, and seems it can't - definition of this function looks like this:

Called when the initial (but not subsequent) render of Gatsby App is done on the client.

In my case it work great, no more scroll retain issue when navigating using Link from Gatsby.

// gatsby-browser.js

export const onPreRouteUpdate = () => {
  document.body.scrollTop = 0
}