Internal anchors with hashes not working

[ediblecode]

Description

Internal anchors with hashes stop working after the first click. See the minimal test case repo at https://github.com/ediblecode/gatsby-anchors-issue and demo site at https://frosty-brown-de3460.netlify.app/. Click into page 2 and click the various internal anchors on that page.

Note: this is using simple anchor tags as per the docs for gatsby link:

Neither <Link> nor navigate can be used for in-route navigation with a hash or query parameter. If you need this behavior, you should either use an anchor tag...

I thought this was fixed by #25749 and released in 2.24.3 but it still seems to be an issue. I think it's related to, if not the same as, #25554, #25745 and #25522. I wonder if it was caused by #24306 (or at least related in some way).

The first anchor seems to be OK but it's definitely something to do with subsquent clicks. Weirdly though it's non-determinate: sometimes it will work fine and sometimes it won't and I can't seem to work out the pattern. Looking into it, session storage is used under the hood for the scroll position, so I wonder if it's something to do with that - maybe the key used isn't including the anchor hash or something? Anyway, that's as far as I got with my digging, sorry. Hoping @blainekasten you might be able to take a look as you've looked at the other related issues. Thank you very much.

Steps to reproduce

1. Clone the gatsby starter
2. Upgrade dependencies to latest via npx npm-check-updates -u
   1. This includes Gatsby 2.24.3
3. Run npm i to install these dependencies
4. Create a page with hash links to elements on a page with matching ids (see example repo and site)
5. Click the internal hash anchors to try to jump up and down the page.

Expected result

The URL is updated with the hash, and the page is scrolled to the element with an id matching the hash in the URL.

Actual result

The first click scrolls to the target element and updates the URL but subsequent clicks only update the URL without moving down the page.

Environment

System:
OS: Windows 10 10.0.19041
CPU: (4) x64 Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
Binaries:
Node: 12.16.3 - C:\Program Files\nodejs\node.EXE
Yarn: 1.16.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 6.14.4 - C:\Program Files\nodejs\npm.CMD
Languages:
Python: 2.7.11 - C:\Python27\python.EXE
Browsers:
Edge: 44.19041.1.0
npmPackages:
gatsby: ^2.24.3 => 2.24.3
gatsby-image: ^2.4.13 => 2.4.13
gatsby-plugin-manifest: ^2.4.18 => 2.4.18
gatsby-plugin-offline: ^3.2.18 => 3.2.18
gatsby-plugin-react-helmet: ^3.3.10 => 3.3.10
gatsby-plugin-sharp: ^2.6.19 => 2.6.19
gatsby-source-filesystem: ^2.3.19 => 2.3.19
gatsby-transformer-sharp: ^2.5.11 => 2.5.11

[annmirosh]

I'm experiencing the same issue and the solution from #25554 doesn't work for me. Any ideas on how this can be fixed?

[dalxds]

exact same issue here!
Sometimes it works fine, sometimes it doesn't.
I think on iOS works correctly most times. Also, if you don't scroll between hitting two anchors (using the menu for example) also works correct most times.
Also, I think the problem is something that came up last 15 days (maybe less) and didn't existed before.
Can't think of anything else that might help.

[ediblecode]

I think I have a workaround that seems to be OK (if hacky). There were various comments on #25554 about downgrading gatsby (e.g. to 2.24.18) or downgrading gatsby-react-router-scroll to 3.0.3. Downgrading gatsby seemed to introduce other issues, for example I came across #20082 and I wasn't a fan of downgrading the whole of gatsby just to fix this issue. So I opted for the specific version of gatsby-react-router-scroll, like the comments.

I checked our existing package-lock.json and it was using gatsby-react-router-scroll@3.0.0, so I went with that version to be safe, although people do seem to suggest 3.0.3 would be OK. (I haven't actually reviewed which version the issue was introduced in).

Unfortunately, the idea of using resolutions in package.json, although great if you're using yarn, didn't work for us as we're using npm, which doesn't support resolutions natively (I wonder if that's the reason for this comment). So instead I used the npm-force-resolutions package to replicate this yarn functionality. So my package.json looks like this:

{
  "scripts": {
+    "preinstall": "npx npm-force-resolutions",
  },
"devDependencies": {
  "gatsby": "2.24.3",
+  "gatsby-react-router-scroll": "3.0.0",
},
+"resolutions": {
+    "gatsby-react-router-scroll": "3.0.0"
+  }

Notice I needed gatsby-react-router-scroll in both devdeps and resolutions to avoid getting "Can't resolve 'gatsby-react-router-scroll' in '.cache'" errors, even though I'm not using it as a dependency directly.

To be honest, it's a bit hacky but it does mean it works as I was being blocked from any new releases because of the functional regression and the trouble I was having downgrading. I can easily back out the line in the diff above when the issue is fixed.

@josephmarkus maybe this could fix your issue?

[josephmarkus]

@ediblecode thanks for the insight. I'll try your suggestion on the latest version of gatsby. In the meantime, my issue was addressed by this fix here - #25749 (and here's the original issue I raised - #25745), namely on a downgraded version of gatsby.

[dalxds]

I am using gatsby themes! should I use the resolution solution to the theme's package.json or the app's (that uses the theme) package.json or both?
thanks!

[ediblecode]

@dalxds not used themes, but probably makes sense to be in the app's I think

[robmarshall]

I am also having this issue.