[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: #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 👍